Skip to content

Keep provider usage requests alive across login-shell env refreshes - #6571

Merged
ymichael merged 1 commit into
mainfrom
bb/fix-issue-6533-in-bb-thr_98w4ay27qx
Oct 29, 2026
Merged

ymichael merged 1 commit into
mainfrom
bb/fix-issue-6533-in-bb-thr_98w4ay27qx

Conversation

@ymichael

Copy link
Copy Markdown
Collaborator

Human comments

What was wrong

Since #6219, providerUsage refreshes the login-shell env with allowStale: true, so the refresh can land while the usage request is still running. When PATH changed, RuntimeManager.replaceBaseShellEnv shut down the provider maintenance runtime immediately, including one with a request in flight, and that request failed with Provider "codex" is not running. With fnm, PATH changes on every probe (eval "$(fnm env)" mints a new fnm_multishells/<pid>_<ms> dir), so every usage call on that host failed. Fixes #6533.

What changed

apps/host-daemon/src/runtime-manager.ts:

  • The maintenance runtime now lives in a slot that counts the requests using it, including requests still waiting for it to start. When the shell env changes or a provider update invalidates it, a busy slot is retired: new requests get a fresh runtime, and the old runtime shuts down when its last request finishes. Idle slots still shut down immediately, and shutdownAll still stops every slot right away, busy or retired. This replaces the old pending/generation/active-count fields.
  • shellEnvEquals ignores the fnm_multishells/<id> segment of PATH entries, so per-shell fnm drift no longer counts as an env change for maintenance or environment runtimes (the trigger behind claude-code: new thread's first turn silently killed by idle-runtime eviction on cosmetic shell-env drift (fnm multishells) — stuck on "Working…" forever #1156).

No wire changes, so there is no HOST_DAEMON_PROTOCOL_VERSION bump.

How you verified

  • New tests in runtime-manager.test.ts:
    • A busy maintenance runtime survives a PATH change, concurrent requests get the fresh runtime, and the old runtime shuts down after its request resolves.
    • An fnm-multishell-only PATH change keeps the runtime, while a real PATH change still replaces it.
    • shutdownAll stops a retired runtime that still has a request in flight.
  • The first two tests fail against the old runtime-manager.ts and pass with the fix.
  • The existing pending-turn eviction test used fnm paths to force an eviction; it now uses plain PATH changes. The stale-creation race test now asserts through the public API instead of a removed private field.
  • pnpm exec turbo run typecheck test lint --filter=@bb/host-daemon: 839 tests passed.

Fixes #6533

AGENT GENERATED

🤖 Generated with Claude Code

Provider usage refreshes the login-shell env with allowStale, so the
refresh can land mid-request. A PATH change shut down the maintenance
runtime the request was using, failing it with "Provider is not running".
With fnm, every probe mints a new fnm_multishells dir, so this happened on
every usage call.

Retire a busy maintenance runtime instead: new requests get a fresh
runtime, and the old one shuts down once its requests finish. Daemon
shutdown still stops it immediately. Shell env comparison now ignores
fnm multishell PATH entries.

Fixes #6533

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@ymichael
ymichael merged commit e852a33 into main Oct 29, 2026
27 checks passed
@ymichael
ymichael deleted the bb/fix-issue-6533-in-bb-thr_98w4ay27qx branch October 29, 2026 19:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Provider usage fails with "Provider is not running" when the login-shell PATH differs per shell (fnm)

1 participant