Skip to content

Changing a provider instance's settings doesn't reach its live sessions #19025

New issue
New issue
Open
Open
Changing a provider instance's settings doesn't reach its live sessions#19025
Labels
acceptedfeature request acceptedbugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

Description

@theg1239
theg1239
opened on Oct 13, 2026

What happened

To work around #16132 and #17445, we switched four managed Codex instances to setupMode: "existing", each with a shadowHomePath that holds its own codex login. T3 picked up the change. It rebuilt each instance, linked the shadow homes, and took the model list from the new logins: the Fast service tier, which the managed provider removes, appeared again. New turns on those instances still went to the old managed app-servers and failed with the managed token error until the sessions were released.

Diagnosis

ProviderInstanceRegistry applies a config change by closing the instance's scope and building it again. Live provider sessions belong to ProviderSessionManager's own scope, so they survive the rebuild.

Outside the manager, only two things release sessions: ProviderAuthService, on sign-in and sign-out, and the ACP actions in ws.ts, through closeInstance. Inside it, a session ends when the adapter's event stream ends, at shutdown, or after 30 idle minutes, and every reuse resets that timer (open → touchActivity).

So a changed setup mode, home path, shadow home, binary path or launch arguments reaches running sessions only after a restart or 30 quiet minutes. We observed this with the setup mode and home paths; the other fields follow from the same code path.

A fix would release an instance's sessions when the registry rebuilds it for a config change, for example with closeInstance once running turns finish. The next turn would then start a runtime from the new config.

Steps to reproduce

  1. Run a turn on a Codex instance so that its shared app-server is running.
  2. Change that instance's settings, for example shadowHomePath, homePath or launch arguments.
  3. Start another turn on the instance. It runs on the old app-server process with the old settings, as ps shows.

Version

0.0.46-nightly.20261011.2980 (ed0f7b908). The relevant files are unchanged on main.

Environment

macOS 27.2 arm64, Node 24.21.0 (Electron), Codex 0.162.1.

Evidence

  • Settings were changed at 10:59:55Z.
  • Within the next two minutes, test turns on three of the instances failed with 401 token_expired from https://api.openai.com/v1/responses, the endpoint only the managed runtime uses.
  • The fourth instance's old app-server had exited earlier: we had killed it while investigating. Its turn failed with Codex App Server process exited with code 0 (see [Bug]: Codex threads stay broken after the Codex app-server exits #17045).
  • ps still showed the three codex app-server -c model_provider="openai_token_sharing" ... processes, whose CODEX_HOME pointed at the old managed shadow homes.

Related issues

Fix applied or workaround

None was needed on the machine beyond the settings change. To apply such a change at once, restart T3. Otherwise, avoid starting turns on the instance for 30 minutes.

Filed by

Claude Opus 5.5 in Claude Code (running inside T3 Code), following the t3 triage playbook.

Activity

  1. juliusmarminge commented on Oct 13, 2026

    @juliusmarminge
    juliusmarminge
    on Oct 13, 2026
    Member

    Note

    Grok responding on behalf of Julius.

    Confirmed on main: this is a bug. ProviderInstanceRegistry documents config changes as hot-reloaded ("tears down the affected instance's scope and rebuilds — that's the entire hot-reload story"). But ProviderSessionManager never subscribes to the registry's streamChanges, so sessions it already holds keep their old runtime. Only the 30-minute idle release (DEFAULT_IDLE_TIMEOUT_MS, which every reuse resets) or a restart clears them. The only callers of closeInstance are the ACP actions in ws.ts, and ProviderAuthService releases sessions only on sign-in/out.

    So restarting isn't the intended way to apply settings. It's just the current workaround: restart T3 Code after changing setupMode, home or shadow-home paths, binary path, or launch args.

    Likely fix: when the registry rebuilds an instance because its config changed, have the session manager release that instance's sessions (closeInstance), after letting in-flight turns finish, so the next turn starts from the new config. This is separate from the credential-renewal issues #16132/#16849 and from #17045's dead-process case, but it should be checked alongside them.

  2. juliusmarminge
    added
    acceptedfeature request accepted
    bugSomething is broken or behaving incorrectly.
    via-triageFiled through npx t3 triage
    on Oct 13, 2026

  3. juliusmarminge commented on Oct 22, 2026

    @juliusmarminge
    juliusmarminge
    on Oct 22, 2026 – with GitCafe Production
    Member

    Reproduced the launch-arguments variant on Linux x86_64, Node 24.21.0, Codex 0.163.0, using the real web dev server and an API-proxy-backed Codex instance at b5a226e49c. This was the cached origin/main; fetching newer main timed out.

    1. Sent “Reply only OK. Do not use tools.” and received OK.
    2. Saved -c issue19025_marker="after" under Settings → Providers → Codex → Launch arguments. Confirmed the isolated server's settings file contained that value.
    3. Sent a follow-up and received OK again. The same app-server processes remained alive, without the new argument:
    PID 1142320: node …/bin/codex app-server
PID 1142391: …/bin/codex app-server
saved launchArgs: -c issue19025_marker="after"

    No duplicate found among 948 open issues scanned in 19 pages. This is an ordinary session-lifecycle bug; the report describes no exploitable vulnerability.

    The managed-to-existing subscription-login transition and macOS/Electron remain unverified here. No fix was written: changing session retirement also changes MCP credential revocation through ProviderSessionManager.releaseEntry, requiring maintainer handling under this triage flow's sensitive-surface stop.

  4. juliusmarminge commented on Oct 22, 2026

    @juliusmarminge
    juliusmarminge
    on Oct 22, 2026 – with GitCafe Production
    Member

    Reproduced again on fetched main 8acbefefc5, Linux x86_64, Node 24.21.0, Codex 0.163.0, using the real web dev server with isolated state.

    A Codex turn returned OK. I saved -c issue19025_marker="after" in Settings → Providers → Codex → Launch arguments, confirmed it in the isolated settings file, and sent a follow-up that also returned OK. Both app-server PIDs remained unchanged and lacked the saved argument. Runtime transcript.

    No duplicate or existing fix found across 927 open issues and 1,394 open PRs. The previous sensitive-surface triage stop no longer applies under the revised brief; this remains an ordinary session-lifecycle bug.

  5. voltcrash
    added 2 commits that reference this issue on Oct 30, 2026

    fix(server): provider settings changes now reach live sessions

    f8c5ecc

    fix(server): provider settings changes now reach live sessions

    5248662

  6. ahmedisam99 commented on Nov 1, 2026

    @ahmedisam99
    ahmedisam99
    on Nov 1, 2026

    Same bug on the Claude driver, with environment variables, on v0.1.6.

    Setup: desktop app (Linux, server 0.1.6), a second Claude instance ("Claude CPA") pointed at a local API proxy with ANTHROPIC_BASE_URL / ANTHROPIC_AUTH_TOKEN in the instance's environment, plus a custom homePath.

    What happened: the token was saved with a stray trailing ', so turns failed with Claude API authentication failed. and 10 provider retries. After correcting the token and base URL in Settings, the next message in the same thread failed the same way. A new thread worked right away.

    Evidence:

    • server.updateSettings at 22:03:49.41Z; the registry rebuilt the instance at 22:03:49.427Z (ProviderInstanceRegistry.buildEntry → makeClaudeEnvironment), and the settings file has the corrected values.
    • The user interrupted the running turn (22:03:53.97Z) and sent a new message (22:03:55.45Z, ProviderSessionManager.holdThreadLoaded → ClaudeAdapterV2.startTurn).
    • The claude --output-format stream-json ... process for that turn started at 22:03:54Z, after the save, but /proc/<pid>/environ still had the old ANTHROPIC_BASE_URL (with trailing space) and the old 65-character token. The proxy answers 401 to the old token and 200 to the new one.

    So this goes beyond long-lived processes being reused: ProviderSessionManager.open (ProviderSessionManager.ts:2137-2156 at v0.1.6) returns the existing session entry, and that runtime spawns new Claude processes with the environment captured when the session first opened. Environment variables are one more field affected, alongside the home path, shadow home and launch args already listed.

    Workaround: start a new thread, or restart the app / leave the thread idle for 30 minutes.

    Triage by Claude Code (Opus 5.5) via t3 triage.

  7. jieyuexing
    added a commit that references this issue on Nov 2, 2026

    fix(server): 实例设置变更后下一次 turn 不再复用旧 provider 进程（取自上游 pingdotgg#28108）

    ce406fb
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    acceptedfeature request acceptedbugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions