[Bug]: Desktop keeps rebuilding the local environment's shell state, causing hard rerenders (nightly 20261005.2667) #16018

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Scope: being sent to the new-thread screen while shell state rebuilds is the cached-shell redirect already tracked in #14689, with a fix open in #14697. This issue is only about the rebuilds themselves: the client keeps recreating environment shell state, which causes the hard rerenders. It also triggers #14689 much more often than the "link to a thread created elsewhere" case it was filed for.

Area

apps/web

Steps to reproduce

1. Run the macOS desktop app on 0.0.46-nightly.20261005.2667 with only the local environment, a few projects and several threads running at once.
2. Keep the window in front for a few minutes.

I don't have a deterministic repro. In my session it happened every 5–40 s while the window was visible and never while it was hidden.

Expected behavior

Shell state for the local environment is built once per app session, then kept up to date over the existing subscription.

Actual behavior

EnvironmentShellState.make keeps running for the same local environment: 21 times in about 7 minutes. Each run reloads the IndexedDB cache, re-subscribes and fetches GET /api/orchestration/shell (~1.5 MB). The UI visibly hard-rerenders each time. The desktop sees the app's readiness (appActivation) flip false/true at the same timestamps (DesktopAppActivation.setRendererReady pairs at 12:25:33, 12:29:48, 12:33:48 local).

What the traces rule out:

• Supervisor teardown. installEntryLocked takes ~0 ms on every 3 s reconcilePlatform, so it returns at the retainEquivalentRuntime check. EnvironmentRpc.getInitialServerConfig doesn't repeat.
• A followStream restart from an entries write. None of the writers of entries show up during the rebuilds: no setCompatibility, setEnabled, learnRoutes, replaceRoutesLocked or removePlatformEnvironment spans.
• A connection blip. EnvironmentSupervisor.signal / rpcSession.probe fired only 3 times and not at the rebuild timestamps.
• A renderer restart or page reload. Same renderer PID throughout.
• Other timers. No consistent correlation with EnvironmentServerConfigState.persist, preview automation focusHost calls, or the 3 s registrations poll.

That leaves the shell stateAtom(environmentId) atom in packages/client-runtime/src/state/shell.ts itself. It isn't keep-alive, so if every component subscribed to it unmounts at once, it is disposed and rebuilt on the next mount. I couldn't confirm what unmounts its subscribers without a debugger on the packaged renderer.

Impact

Major degradation or frequent failure

Version or commit

T3 Code (Nightly) 0.0.46-nightly.20261005.2667 (37de6cb), desktop.

This looks like a regression in this build: setRendererReady flaps went from a few per day up to the 11:37 auto-update from 20261004.2657 to every few minutes afterwards. I looked at the two client-runtime connection changes in that range, #15467 and #15468, and the traces don't implicate them for the local platform environment (see above). None of the 6 commits on main after 37de6cb touch shell.ts, registry.ts, runtime.ts or ThreadRouteView.tsx.

Environment

macOS (Apple silicon), Electron 44.4.2 / Chrome 152, desktop app with only the local environment, background activity profile performance. Several Claude Agent and Codex threads running at the same time, one using preview automation.

Logs or stack traces

# server.trace.ndjson (client otlp spans), local time
12:24:59 EnvironmentShellState.make
12:25:05 EnvironmentShellState.make
12:25:33 EnvironmentShellState.make   # + setRendererReady false/true
12:25:42 EnvironmentShellState.make
12:25:50 EnvironmentShellState.make
12:26:11 EnvironmentShellState.make
12:26:53 EnvironmentShellState.make
...
12:29:48 EnvironmentShellState.make   # + setRendererReady false/true
...
12:31:17 EnvironmentShellState.make

# one rebuild (ms relative to make); make is a root span
-908  EnvironmentRegistry.reconcilePlatform / installEntryLocked (0 ms, runtime retained)
 -13  EnvironmentServerConfigState.persist
  -1  EnvironmentRegistry.acquireSupervisor
   0  EnvironmentShellState.make
 +24  environment.initialSync -> fetchEnvironmentShellSnapshot -> GET /api/orchestration/shell (200, 1.48 MB)

Workaround

None reliable. #14697 would stop the redirect half. Rolling back to 0.0.46-nightly.20261004.2657 might help if this is a regression in today's build.

Investigated with Claude Code (Claude Opus 5.5) from local trace logs, the shipped bundle and the source at 37de6cb.