Repository navigation
Connected Services: manual Claude pool change is policy-rejected before turn-boundary deferral, with a generic auth-switch error #627
Description
Summary
Changing an existing Claude session from one Connected Services pool to another fails at the continuity execution-policy gate. The operation does not reach the manual restart deferral queue, and the client presents a failed authentication-switch operation without explaining the policy restriction or offering a safe handoff.
Observed behavior
- A manual change to a different pool was refused because continuity required a restart that the execution policy disallowed. The failure was classified as retryable.
- The session retained its original pool binding and continued working with its goal active. No runner exit was observed from this switch attempt.
- An earlier automatic account rotation within the original pool succeeded through live application while the goal was active.
- The destination pool's selected member was marked connected. That stored status does not establish that a fresh provider authentication would succeed, but the observed refusal occurred at the execution-policy gate rather than a provider credential rejection.
- The failed request did not become a deferred pool change.
Source-based diagnosis
In the installed CLI, gateRestartResumeBeforeSideEffects calls the switch apply policy before the restart callback. evaluateConnectedServiceSwitchApplyPolicy forbids restart and resume when the provider advertises direct live authentication support, including the manual-switch context. Claude advertises that capability, although this cross-pool continuity decision requires a restart.
The manual handler has a turn-boundary deferral queue inside its restart callback, but this refusal returns before that callback. The relevant policy decision does not consult goal status or current turn activity. Disabling a goal or waiting until idle is therefore not an established workaround.
The inspected public UI source also lacks this policy refusal in its switch-error mapping and falls back to the generic failed-switch message. The deployed iOS client source was not independently verified.
Synthetic reproduction recipe
These names and tasks are invented. This is a proposed clean-environment recipe, not a claim that these exact steps were executed in a fresh test environment.
- Configure two Claude subscription pools named Pool A and Pool B, using test accounts.
- Start a Claude session bound to Pool A. Use a disposable goal involving several arithmetic checks.
- While a turn is active, use the session's authentication selector to choose Pool B.
- Check whether the request receives an execution-policy refusal, retains Pool A, and has no pending change for the next turn boundary.
- As controls, repeat with no active goal and with an idle session. Separately compare account rotation within one pool.
Expected behavior
Preserve the active turn and session continuity. Where a safe deferred switch is supported, retain the request, show that it is pending, and apply it at the appropriate boundary. Where the policy prohibits the transition even at idle, explain that restriction, identify the pool still in use, and offer a supported continuity-preserving handoff. A credential-reconnect message or an unexplained retry should not stand in for a policy refusal. Keep the restart safety guard.
Environment and scope
CLI and daemon: stable 0.2.16. Worker: Windows. Client: iOS, exact build not captured. Deployment: self-hosted.
This concerns changing the session's pool selection. It differs from #370, which concerns a running Codex session failing to adopt an account change inside its existing pool, and #441, which concerns a Codex turn being aborted by account rotation.
No private logs, conversation excerpts, screenshots, project details, file paths, hostnames, account names, pool identifiers, or session identifiers are included. Only product behavior, public code symbols, and synthetic reproduction data are provided.
Activity
fix(ui): explain connected-service restart policy refusals
happier-bot commentedon Oct 20, 2026
Thanks for tracing the refusal to the policy gate. Changing Claude pools can change the materialized authentication home and require a restart. Rotation between members of the same pool can retain that home.
In the current 0.2 implementation, policy rejects this restart before it reaches turn-boundary deferral. Waiting until idle or disabling the goal therefore does not resolve it.
We’ve corrected the generic app feedback in source, while preserving the restart guard. This is not yet a released-app fix.
If these accounts should rotate for the same workflow, keeping them in one pool is the supported direction. Do they need separate pool policies? That would help establish the requirement for a planned cross-pool restart and handoff.
Posted on behalf of @leeroybrun.