Thread from an offline T3 Connect environment cannot be settled, archived, or deleted from another device #24563

What happened

I had a thread that ran on my Windows laptop and showed up in the sidebar on my MacBook through T3 Connect. The thread was done but not yet settled. I turned the Windows laptop off. Afterwards I could not settle the thread from the MacBook: Settle, Delete and Archive all failed with a toast saying the machine is not connected. There was no way to get the thread out of my sidebar. I worked around it by turning the Windows laptop back on and settling from there. If I no longer had that machine, the thread would be stuck in the UI until I remove the whole connection.

Minor, but annoying: a thread that is already Done should not need its origin machine online just to be dismissed.

Diagnosis

This is the part of #4852 that the maintainer said was still open when closing it on 2026-10-21 ("stop, settle, archive, delete, pin, and snooze still require the environment to reconnect. If that part still matters to you, please open a new issue for that part only"). No follow-up issue exists yet, so this is it.

Mechanism in the build this happened on (nightly 0.1.3-nightly.20261024.3630, commit d53873b):

• Settle, archive, delete, pin and snooze are environment commands. packages/client-runtime/src/state/threadCommands.ts wraps each in createEnvironmentCommand, which runs the command inside the environment that owns the thread (packages/client-runtime/src/state/runtime.ts).
• Every RPC to that environment first resolves the current session in packages/client-runtime/src/rpc/client.ts:134-148. When the environment has no live session the call fails immediately with EnvironmentRpcUnavailableError: "<label> is not connected.". There is no local fallback, no queued delivery for when the peer reconnects, and no client-local per-thread hide state.
• The thread row itself is a cached projection of the remote server's state. It renders as Offline (from fix(app): show threads from unreachable environments as offline #8935), so the display side is fine. Only the lifecycle actions are blocked.
• The "Disconnect server" escape added in fix(web): disconnect offline servers from threads #11671 lives in the composer banner (apps/web/src/components/chat/useSystemComposerBanners.tsx) and only triggers for the active environment. It does not help when the offline environment is a secondary one whose single thread sits in the sidebar while you keep working on the local machine.
• While the peer is offline the client also keeps sending server.reportClientActivity to it and fails every few seconds (279 failures in 45 minutes on this machine). Harmless, but it is the same code path and shows how noisy an offline peer is.

Expected: a thread whose environment is offline can be settled, archived, deleted or snoozed from another device, either applied locally and replayed when the peer reconnects, or at least hidden locally. Failing that, the actions should be disabled with a short "machine offline" note instead of a failing toast. PR #22768 (draft) proposes reversible local hiding and would cover this.

Steps to reproduce

1. Machine A (macOS desktop app) and machine B (Windows desktop app) linked through T3 Connect.
2. On B, run a thread to completion. Do not settle it.
3. On A, confirm the thread is visible in the sidebar under its project.
4. Shut down B.
5. On A, wait until the thread row shows Offline, then try Settle, Archive, or Delete on it.

Result: each action fails with a toast <B> is not connected. The thread cannot be removed from the sidebar on A. Turning B back on and settling there is the only way out, apart from Settings → Connections → Remove, which drops the whole environment.

Version

0.1.3-nightly.20261024.3630 on both machines (desktop app).

Environment

Machine A: macOS 27.0.0 (darwin arm64), Node v24.22.0, T3 Code Nightly desktop app, local server 0.1.3-nightly.20261024.3630. Machine B: Windows laptop, T3 Code Nightly desktop app, same version. Linked via T3 Connect.

Evidence

# server.trace.ndjson on machine A while machine B is powered off (environment id truncated).
# Same failure class every RPC to the offline environment hits; the thread lifecycle commands
# go through the same EnvironmentRpc.currentSession check.
{"type":"otlp-span","name":"EnvironmentRpc.request","attributes":{"environment.id":"5a4edb53-…","rpc.method":"server.reportClientActivity"},
 "events":[{"name":"exception","attributes":{"exception.type":"EnvironmentRpcUnavailableError",
 "exception.message":"<windows laptop> is not connected.",
 "exception.stacktrace":"EnvironmentRpcUnavailableError: <windows laptop> is not connected.\n    at onNone (t3code://app/assets/runtime-CAtAZZ0F.js:5:29927)\n    at EnvironmentRpc.currentSession (t3code://app/assets/runtime-CAtAZZ0F.js:5:30640) ..."}}]}

# 279 such failures between 22:18 and 23:03 local while the peer was off (one every ~10 s).

Source, commit d53873b:

packages/client-runtime/src/rpc/client.ts:134-148   currentSession -> EnvironmentRpcUnavailableError "<label> is not connected."
packages/client-runtime/src/state/threadCommands.ts:198-224   delete/archive/settle are createEnvironmentCommand(...)
packages/client-runtime/src/state/runtime.ts:732   createEnvironmentCommand -> runInEnvironment(target.environmentId, ...)

Related issues

#4852 (closed completed on 2026-10-21; this is the explicitly requested follow-up for the still-open part), #8924 and #12140 (closed as duplicates of #4852, same symptom), #8935 (Offline rendering, merged), #11671 (Disconnect server for the active environment only), #22768 (open draft PR for local hiding), #22887 (open PR, reorder around offline rows). Not a duplicate: #4852 is closed and its maintainer asked for a new issue for exactly this part.

Fix applied or workaround

Nothing changed on the machine. Workaround used: power the origin machine back on and settle from there. Alternative: Settings → Connections → Remove, which removes the environment and all its cached threads.

Filed by

Claude Fable 5.1 (claude-fable-5-1) in Claude Code, via t3 triage.