Reconsider host-level agent auth state

[Qusic]

Currently each client must independently obtain OAuth tokens and push them to the host via authenticate. The token lifecycle (refresh, expiry) is also per-client. In practice this means the host holds N copies of the same Copilot
token for N connected clients — all granting access to the same GitHub account on the same machine.

The per-client isolation this model assumes doesn't exist in practice. In the VS Code agent host, all clients share a single process. Any connected client can execute arbitrary commands and access credentials on the host via tool
calls. Per-client token isolation would only be meaningful with per-client sandboxing, which the current architecture doesn't provide.

Suggestion: Make agent auth state host-level. The host manages tokens for agents like Copilot centrally — obtaining, storing, and refreshing them. Clients authenticate their connection to the host (--connection-token), not
separately with each agent's upstream service.

Clients could still assist with the initial auth flow when the host has no token (e.g. presenting a device code UI and passing the result back), but the token would be stored and refreshed by the host, shared across all
connections. This also simplifies reconnection — clients don't need to re-push tokens after a dropped connection.

ahpx already works around this by resolving GitHub tokens from the environment (GITHUB_TOKEN / gh auth token) client-side — effectively treating agent auth as a host-level concern.

Spec references

• Per-client auth flow: authentication.md#L7-L25
• Per-resource, not per-connection: authentication.md#L197-L202
• Per-connection rationale: authentication.md#L204-L206

[connor4312]

This is actually a bit of a bug in the VS Code Agent host. The credential should be less-shared than it is today and more tied to the client, although the agent host does need to retain that token for a while when the session is ongoing after disconnect. The VS Code agent host all goes through Copilot/CAPI currently, but you can easily imagine future agent host implementations where other harnesses/agent implementations are plugged in to other 3rd party services.

But that said I agree the harness-level implementation of auth is not necessarily correct. Even in that world ^ there could readily be cases where you use the Copilot harness but BYOK to another provider for certain models.

So maybe the solution now is we just drop AgentInfo.protectedResources and let agent hosts throw a -32007 AuthRequired error when the client tries to do something that needs auth.

cc @roblourens @TylerLeonhardt

[Qusic]

Thanks for the response.

I agree -32007 as the sole discovery mechanism makes sense — it's simpler and already handles the BYOK case naturally.

One thing I'm still not clear on — these two points seem to pull in opposite directions:

The credential should be less-shared than it is today and more tied to the client

the agent host does need to retain that token for a while when the session is ongoing after disconnect

If the host retains and uses the token independently after a client disconnects, isn't that de facto host-level state? A second client connecting later would see an ongoing session powered by the first client's token — what happens
then?

It seems like "per-client" in practice means "whoever pushed last wins," which is fine, but it's really host-level state with client-assisted acquisition.

[connor4312]

Yea, I think the model is generally that whatever client sent a message last is the one who's token gets used for that session.

I don't want to enshrine agent hosts and long-term token managers, or at least not mandate it, since we have scenarios where people are starting to run agent hosts in sandboxes which are (a) ephemeral and (b) should be treated at arms length, and only get short lived tokens that clients explicitly choose to send (i.e. clients should treat any sandboxed agent host as potentially compromised) rather than managing long lived refresh tokens.

I would not do anything in the protocol to block the token manager scenario, but neither should it be mandated.

[Marsssssssssssdsss]

Hi @Qusic, the N-copies-of-the-same-token problem is a classic symptom of conflating transport credentials with agent identity. Each client holding its own copy means any client can end up with a stale token while others have fresh ones.

A cleaner model is to give each agent its own cryptographic identity that doesn't change between sessions, and have the host verify the agent's identity rather than managing tokens on its behalf. The token becomes a short-lived proof of authorization tied to that identity, not something that needs to be copied across clients.

It shifts the problem from 'keeping N tokens in sync' to 'verifying one agent identity consistently.' Curious if this matches your thinking.