ACP v0.13.3 Makes Logout Part of the Agent Safety Model

ACP v0.13.3 Makes Logout Part of the Agent Safety Model

Logout is not the glamorous part of an agent protocol. Nobody demos it onstage. Nobody posts a benchmark showing “credential revocation throughput.” But Agent Client Protocol v0.13.3 stabilizing logout is exactly the kind of release note that tells you whether the agent ecosystem is growing up or merely adding more ways to call tools.

The short version: ACP v0.13.3 promotes logout from unstable plumbing into a stable protocol method. The release also renames unstable provider method types to singular forms, moves the additional-directories request-for-discussion to Preview, adds schema download guidance, sets a minimum supported Rust version, and documents versioning semantics. That reads like housekeeping until you remember what coding agents are starting to hold: repository access, provider sessions, MCP credentials, issue trackers, cloud consoles, internal docs, and filesystem authority that often extends beyond a single project directory.

Once agents own real credentials, “sign out” stops being a UI nicety. It becomes part of the safety model.

Credential lifecycle is now protocol surface area

The v0.13.3 release was published on May 22, 2026, with the ACP repository sitting at roughly 3,201 stars, 256 forks, and 35 open issues during research. The stabilizing change came through PR #1273, which landed 414 additions and 184 deletions across 22 files. That is a non-trivial patch for a verb that sounds simple.

The reason is that logout means different things if it is left to every client and server to improvise. Does it clear a local token? Revoke an upstream refresh token? End a provider session? Remove cached account metadata? Disconnect one provider or all providers? Update the UI immediately or wait for server confirmation? In a single app, those details are annoying. In a protocol meant to connect editors, terminals, hosted workspaces, agent servers, and SDKs, ambiguity becomes a compatibility bug with security consequences.

Stabilizing logout gives implementers a shared lifecycle contract: clients can ask for credential state to end, servers can implement that behavior predictably, and test suites can assert it. That is the boring foundation enterprise agent deployments need. Shared machines, contractor laptops, remote development containers, VDI environments, and managed workspaces all have the same requirement: the user must be able to leave without leaving the agent holding yesterday’s authority.

This is also where agent protocols differ from chat APIs. A chat session can be disposable. A coding agent session is attached to accounts, filesystems, terminals, tools, and sometimes long-running background work. If login is standardized and logout is tribal knowledge, the protocol is only half-finished.

The directory-scope signal is bigger than it looks

The other forward-looking change is PR #1276 moving the additional-directories RFD to Preview. That is protocol-speak for “this is not fully stable yet, but downstreams should start paying attention.” They should.

Coding agents rarely live inside the clean boundary product screenshots imply. Real work touches sibling repositories, generated SDKs, monorepo packages, shared documentation, local fixtures, infrastructure modules, design-system packages, and test data that sits outside the current checkout. If the protocol cannot represent that authority clearly, clients will fake it. The usual fake is broad filesystem access with a polite warning. That scales about as well as giving every browser extension “read and change all your data” because one workflow needed access to one tab.

Additional-directory semantics are therefore not just convenience. They are how an agent client says, “This workspace is the main project, and these other roots are explicitly in scope.” That distinction matters for audit logs, prompts, file pickers, policy enforcement, and user consent. It also matters when the agent is wrong. If an agent deletes or rewrites something outside the project root, the first question will be whether it was allowed to see that path at all. Protocols need to make that answer inspectable.

Practitioners should treat this as a design prompt. If your internal agent runner currently mounts a whole home directory or developer machine into the tool sandbox because path scoping was inconvenient, that is technical debt with a badge on it. Start modeling the actual roots your workflows need. Keep the list narrow. Make additional access visible in the client. And test denial paths, not just happy paths.

Small naming fixes are how protocols avoid permanent weirdness

PR #1272 renames unstable provider method types to singular forms because the methods operate on one provider at a time. That sounds cosmetic until you have lived with an API whose names imply batch behavior it does not support. SDK authors make assumptions. Client developers mirror those assumptions in UI state. Documentation accretes workarounds. Then the wrong name becomes load-bearing.

The useful thing here is not the rename itself. It is that ACP is doing the cleanup while the surface is still unstable. Stable protocol names should be dull, precise, and hard to misread. Unstable namespaces are where you get to break the shape before everyone builds on it. That discipline matters in agent infrastructure because the downstream graph gets messy quickly: TypeScript SDKs, Rust servers, editor plugins, terminal clients, hosted runners, MCP bridges, custom enterprise wrappers, and internal platform teams all depend on the same nouns meaning the same thing.

The schema download note and versioning semantics documentation belong in the same bucket. Protocol adoption is not only about what the protocol can express. It is about whether tooling can validate messages, generate clients, and decide which changes are safe to take. ACP explicitly separating stable additions, unstable fixes, RFD movement, docs, and dependencies is the kind of release hygiene that lets downstreams upgrade without treating every minor version as a weekend migration.

What builders should do now

If you implement ACP, add logout to your integration suite as a first-class flow. Test provider logged in, provider already logged out, token revoked upstream, server restart, client restart, multiple providers configured, and logout while a session is idle versus active. The failure mode to avoid is the fake logout: UI says disconnected while the backend can still act with cached authority.

If you consume ACP through a client or SDK, ask where the credential actually dies. Local cache cleared is not the same as upstream revocation. Upstream revocation is not the same as stopping a running agent job. A good implementation should make those boundaries explicit enough that an operator can reason about them without reading the source.

If you are building internal agent platforms, do not wait for additional-directories semantics to become boring before thinking about filesystem policy. Inventory the roots your agents need. Separate read from write where possible. Deny Git hooks and config-like execution surfaces unless there is a specific reason. Log directory grants in a way humans can review later. The agent that needs three sibling repos for a build is a different risk profile from the agent that has the whole developer workstation.

The broader pattern is clear: agent infrastructure is moving from “can the model call the tool?” to “can the runtime govern the authority it gives the model?” Logout, provider naming, schema availability, versioning semantics, and directory scoping all live in that second category. They do not make demos sparkle. They make adoption survivable.

ACP v0.13.3 is a minor release in version-number terms, but the direction is the story. The protocol is accumulating lifecycle verbs and policy surfaces instead of just capability surfaces. That is exactly where coding agents need to go. Once an agent can edit your repo, authenticate to your tools, and roam outside the current directory, “log out” and “which directories?” are not afterthoughts. They are the part of the contract you will be grateful for when something goes sideways.

Sources: Agent Client Protocol v0.13.3 release, PR #1273 — stabilize logout method, PR #1272 — provider method type rename, PR #1276 — additional directories RFD preview, PR #1229 — ACP versioning semantics.