Converge chat and triage on one Claude credential, and stop trusting the sender login unsigned

[imaustink]

Applying the ai-triage label on #161 asked me to authorize Claude, while chat had been launching agents all day on the same account. The orchestrator's own logs, fifteen minutes apart:

15:57 [authorization] {"verdict":"authorized",   "agentId":"claude-code-swe-agent", "actorLogin":null}
16:12 [authorization] {"verdict":"link-required","agentId":"claude-code-swe-agent", "pending":["claude@github:imaustink"]}

ADR 0029's cross-entry-point sharing was working in one direction only. A webhook turn always carries a verified senderLogin, so it always resolved a principal and read claude@github:imaustink. Chat could only read a login off an existing github link — and one of those was only ever created as a side effect of an Agent's identityProviders, which ADR 0030 §5 removed github from to fix a production 401. So the fix for the 401 silently switched off sharing for every chat caller. Neither flow was broken alone; they never met, and no amount of authorizing in one fixed the other.

What changes

Establishing a principal is its own pre-flight step (ADR 0031), independent of what the Agent declares: an ordinary github link that is link-only — its token is never injected, so no GITHUB_TOKEN reaches the run and the agent's delegated-write path (the observed 401) stays unreachable. Mapping and credential provisioning are now separately reachable, which is what §5 asked for and had no mechanism for.

Existing credentials are moved, not re-authorized. Both flows reading one key doesn't put anything at that key — records written before principals existed sit under the entry point's own subject. The gateway gains ClaudeTokenStore.rekey + POST /claude-auth/api/rekey, and the pre-flight adopts lazily on the turn that needs it. So converging costs a chat user one GitHub link and zero re-authorization.

The unsigned sender login is closed. Neither AGENT_SENDER_ASSERTION_SECRET nor GATEWAY_SENDER_ASSERTION_SECRET exists on the live deployment, so the orchestrator trusts the sender login from the /invoke body, unsigned — and that field selects whose stored credentials a run gets. The mechanism has existed since ADR 0030; what was missing is that these Secrets are hand-created and nothing said to include the key. e2e's bootstrap already sets it, so minikube ran the signed path while production ran the unsigned one.

Security properties, each pinned by a test

• Identity.perUser — newly asserted by the one resolver that knows it structurally (OpenWebUiForwardedUserResolver) — gates both establishing a principal and adopting a credential. A login filed under the gateway's shared service subject would be inherited by every later senderLogin-less webhook turn, handing one person's credentials to everyone. progressListener ("has a live channel") was tried as the signal and rejected: a shared subject on a streaming caller passes it, so it's unsound in the one direction that leaks.
• A pending principal link stops the turn rather than filing the credentials the user is about to create under a subject they're one link away from abandoning. A deliberate exception to §4's batching, which assumes providers are independent.
• Rekey moves, never copies (the claude-remote write-back only writes the new key, so a copy rots into "Login expired"), never overwrites the destination, and deletes the source only after reading the destination back — set swallows its own Redis errors, so an unverified delete could drop someone's only credential.
• Provider order stays irrelevant (§4), and every failure degrades to the raw subject rather than blocking: sharing is an improvement, not a precondition.
• The authorized verdict now carries its principal and delegateToAgent adopts it — otherwise the expired-credential path invalidates a record that was never written and tells the user to retry, the infinite loop that path exists to prevent.

e2e now drives both entry points

The suite existed to catch keying bugs and couldn't see this one, structurally: every spec drove webhooks, so the flow that couldn't resolve a principal was unreachable from a test. e2e/support/chat.ts mints the per-user X-OpenWebUI-User-Jwt and posts a streaming /v1/chat/completions; chat-harness.e2e.ts checks that minting against the real resolver and needs no cluster, so harness/product drift fails fast instead of surfacing as "could not resolve caller identity" inside every chat spec.

The rule worth keeping, now in e2e/README.md: when behaviour differs per entry point, cover it from each of them. Every keying bug in this repo's history has been an asymmetry between the two.

Review notes / limits

• The prod Secret is not patched by this PR. Run ./scripts/provision-sender-assertion-secret.sh — one generated value, both Secrets, digest-compared before anything rolls, then gateway first, orchestrator second. That order is load-bearing: gateway-set/orchestrator-unset is exactly today's behaviour, while the reverse makes every webhook turn lose its sender login and re-prompt.

• Run on minikube: all 11 pass (4 webhook + 4 chat + 3 harness, 12.5 min), against images built from this branch. The rekey route was also smoke-tested against the live gateway store: 200 {"status":"not-found"}, 400 on malformed input, unknown actions still 404. The orchestrator's own logs show a chat turn resolving principal: github:e2e-user — the key a triage turn reads — and openwebui:e2e-chat-user in the no-link case.

  The run found two defects, both in my harness rather than the product, fixed in f9f6177 + 2303fde:

  • The planner preferred opencode-swe-agent over the agent the request named. It declares no identityProviders, so the pre-flight iterated an empty list and launched with no credential resolved — a silently-passing spec, not a weaker one. Pointing the triage route away from it sufficed while every spec arrived through an IntegrationRoute; chat has no route, so it is now disabled in the e2e overlay entirely.
  • chatTurn treated a parked turn as a failure, when parking is the product working (a turn needing a link holds open for the flow expiry). Now explicit via allowPark. Two attempts to get right: the abort fires on the body read, not fetch (SSE headers flush immediately), and AbortSignal.timeout rejects with a DOMException that fails instanceof Error — either alone made the option a no-op. Also cut that spec from 845s to 93s.

• The GitHub link is seeded in e2e, not established — a real device/authcode round trip needs github.com and a browser. The orchestrator reads only githubLogin off that record, so the path under test is identical; the OAuth exchange itself stays uncovered, as before.

• Not fixed here: resolveActorLogin still trusts a github link under whatever subject it finds, including a shared one, if a leftover record exists there (the identity-link store has no TTL). This change never creates one there. Removing that hazard belongs with ADR 0030 §6's alias table.

• Commits are ordered so each builds and tests on its own: rekey capability → convergence that uses it → e2e → prod bootstrap.

Verified: all workspaces green (451 orchestrator, 236 gateway, 3 harness), typecheck clean at each commit, helm template renders for both e2e and production values.

🤖 Generated with Claude Code

https://claude.ai/code/session_01W7XfNb5HsmaZH7QyxUrbyB

[imaustink]

Ran the suite on minikube against images built from this branch: 11/11 pass (4 webhook + 4 chat + 3 harness, 12.5 min).

Two defects surfaced, both in the harness rather than the product — recorded because each was invisible to typecheck and one of them passes silently:

1. The planner preferred opencode-swe-agent over the agent the request named. It declares no identityProviders, so the authorization pre-flight iterated an empty list and launched with no credential resolved at all. Every weaker assertion in the spec still passed. Pointing the triage route away from that agent was enough while every spec arrived through an IntegrationRoute — a chat turn has no route, so it is now out of the e2e catalog entirely.
2. chatTurn treated a parked turn as a failure. A turn that needs an account link and has a live channel deliberately holds its connection open for the whole flow expiry, so for the negative control parking is the correct outcome. Now explicit via allowPark, leaving a genuine hang failing loudly elsewhere.

Also smoke-tested the new gateway route against the live store: 200 {"status":"not-found"}, 400 on malformed input, and unknown actions still 404 (so it is genuinely registered, not swallowed by a catch-all).

Body updated — the "not executed" caveat is gone.