[Bug]: Nightly runtime reconciliation cancels live Claude turns and causes false login/provider-start failures #17162

Before submitting

• Searched existing issues. Related: [Bug]: Desktop starts a second backend against the background service database #6097, but this report involves the canonical desktop environment without a deliberately running background T3 service.
• Included version, observed timeline, and sanitized diagnostics.

Area

apps/server (provider runtime lifecycle / desktop)

Summary

After upgrading to nightly, Claude sessions repeatedly stop with provider-start or authentication errors even though the native Claude CLI remains authenticated and can perform real inference. Runtime reconciliation marks a live turn cancelled, a continuation fails, and the original Claude process can continue working after the UI considers it cancelled.

This has recurred after a local mitigation, so this is not a resolved configuration issue. The exact initiator of the later reconciliation events remains unidentified.

Steps to reproduce / observed workflow

1. Use the nightly desktop app with the canonical ~/.t3 environment and Claude Code subscription authentication.
2. Start or resume a Claude conversation, allow it to perform tools and work, then continue the existing thread.
3. In this environment, the running turn is intermittently cancelled through runtime-reconcile:startup or runtime-reconcile:shutdown.
4. An automatic "Continue where you left off." turn fails with authentication_failed, "Not logged in · Please run /login", or the generic provider-start error. Further attempts can report that a provider turn is still active.

This is an observed recurring workflow, not yet a minimal deterministic reproduction. Earlier health tooling invoked t3 auth session issue/revoke --base-dir ~/.t3; those invocations correlated with reconciliation of live sessions. Removing those invocations stopped reconciliation during three controlled health checks, but the failure later recurred. Therefore that tooling was a trigger, not a proven complete explanation.

Expected behavior

Only the owning runtime should reconcile/shut down its live provider sessions. CLI authentication/administrative commands and unrelated runtimes should not cancel a desktop-owned turn. A cancelled turn should not leave the native provider doing untracked work. Existing authenticated sessions should resume successfully, and errors should reflect the actual failure.

Actual behavior

• Active turns become cancelled without a user cancellation.
• A continuation immediately fails with a login error despite healthy native CLI authentication.
• Subsequent attempts fail to start or say a provider turn is still active.
• The original Claude process can remain active and write work after the cancellation recorded by T3.
• Recovering the thread locally does not prevent another occurrence.

Impact

Major degradation / repeatedly blocks ongoing Claude work. Existing conversations become unreliable and require manual diagnosis and recovery.

Version or commit

T3 Code 0.0.46-nightly.20261008.2813 (orchestration protocol 2).

Environment

• macOS 27.0.1, build 26A434, Apple Silicon
• T3 Code Nightly desktop app
• Claude Code 2.1.293
• Model claude-opus-5-5
• Subscription authentication (claude.ai), full-access / bypassPermissions
• Canonical ~/.t3/userdata/statev2.sqlite
• Desktop backend remained alive on port 3774 throughout the observed cancellation; no retired background service was intentionally running

Logs / diagnostic evidence

Times below are UTC on 2026-10-08. Thread identifiers are anonymized.

09:27:56.407Z  THREAD_A run 2 requested
09:30:22.846Z  runtime-reconcile:startup:THREAD_A; run 2 -> cancelled
09:30:22.878Z  THREAD_A run 3 requested (continuation)
09:30:23.976Z  run 3 -> failed
09:30:34.560Z  THREAD_A run 4 requested
09:30:34.793Z  run 4 -> failed
09:32:45.758Z  runtime-reconcile:shutdown:THREAD_A; turn-item.updated
09:33:07.366Z  runtime-reconcile:startup:THREAD_A; turn-item.updated
09:43:08.603Z  THREAD_A run 5 requested (manual recovery)
09:44:25Z      genuine Claude SDK thinking frames observed
09:45:52.414Z  runtime-reconcile:shutdown:THREAD_A; run 5 -> cancelled
09:45:56.792Z  THREAD_A run 6 requested
09:45:57.826Z  SDK assistant error: authentication_failed
               Not logged in · Please run /login
09:45:57.846Z  run 6 -> failed
SDK result: is_error=true; terminal_reason=api_error

User-visible errors:

The provider could not start this turn. Retry the turn; if it keeps failing,
check the provider setup and server logs.

Claude could not authenticate. For subscription login, run `claude auth login`
on this environment's machine, then start a new thread.

Claude provider turn ... is still active.

claude auth status independently reported authenticated subscription login. A fresh native CLI inference at approximately 09:42 UTC succeeded and returned the requested AUTH_OK response. No re-login was needed to restore that CLI inference.

Some reconciliation traces describe server.mode=web, server.port=3773, server.host=127.0.0.1, while the existing desktop backend stayed alive on port 3774. The process responsible for those later startup/shutdown traces has not been isolated.

Suspected lifecycle issue (not a confirmed complete root cause)

In the installed bundle, ServerRuntimeStartup registers an unconditional scope finalizer that interrupts the worker, executes providerRuntimeRecovery.prepareForShutdown with providerSessions.shutdown, and then calls providerRuntimeRecovery.reconcile("shutdown").

const workerFiber = yield* getAndSet(effectWorkerFiber, null);
if (workerFiber !== null) yield* interrupt$4(workerFiber).pipe(ignore$1);
yield* providerRuntimeRecovery.prepareForShutdown.pipe(ensuring(providerSessions.shutdown));
const reconciliation = yield* providerRuntimeRecovery.reconcile("shutdown");

Please investigate whether acquiring/disposing shared layers for a CLI command or a non-owning runtime can reconcile sessions belonging to the live desktop runtime, including when its worker was never started. Also investigate provider process ownership after cancellation and why resumed processes report authentication failure while a fresh native invocation succeeds.

Workaround

Removed CLI session issue/revoke calls from local health tooling and recovered affected threads by carefully stopping verified orphan provider processes before resuming. Three health-check cycles then passed without reconciliation, but a later active turn was cancelled again and its continuation failed. This is only a partial mitigation, not a durable fix.

No raw auth stores, tokens, process arguments, personal screenshots, or private repository content are included.