[Bug]: Imported threads that never ran sit in Working as Waiting#33024

Before submitting

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

Area

packages/contracts or packages/shared

(The defect is in packages/client-runtime, which both apps/web and apps/mobile use.)

Steps to reproduce

1. Import Claude Code sessions into T3 Code.
2. Leave an imported thread unsettled and unsnoozed, or let its snooze expire. Do not send it a message from T3.
3. Look at the sidebar.

Expected behavior

The imported thread reads as Ready, like any native thread whose turn has finished. It is the user's turn, not a running agent's.

Actual behavior

The thread sits in the Working shelf with the grey Waiting label and stays there indefinitely. Nothing runs in it. The Waiting timer has no start, because the thread has no run.

On my install, 229 imported threads have no runs. 212 are settled and 6 are snoozed, so they are hidden. The other 11 all show as Waiting in Working. The two imported threads I continued in T3 have runs and display correctly.

Cause

The server reports a thread with no runs as status: "idle" (latestRun?.status ?? "idle" in apps/server/src/orchestration-v2/ProjectionStore.ts).

On the client, shellRuntime in packages/client-runtime/src/state/models.ts returns null for a thread that never ran only when activeProviderThreadId is also null. An imported thread has its provider thread bound, so it gets a runtime whose status is the server's "idle". deriveThreadStructureRuntime in threadExecution.ts has the same condition.

In the client, runtime status "idle" means "the agent stopped with background work still open". resolveSidebarThreadStatus maps it to waiting, and the Working shelf takes waiting threads. So "never ran" is presented as "parked on background work".

Impact

Minor bug or occasional failure

Version or commit

T3 Code (Beta) 0.1.7 desktop. Code paths checked on main at ade47301.

Environment

macOS desktop app, local server, Claude provider.

Logs or stack traces

Shell for one affected thread, from the MCP thread read (the projection has historyOrigin: "v1_import"):