Sign up
View stargazersSign up

[Bug]: Threads remain permanently Working when environment is unavailable#4852

openedJul 29, 2026byNnelsonsbrian

Area

apps/web / thread lifecycle and environment connectivity

Summary

Threads from a permanently unavailable environment remain stuck in a perpetual Working state and cannot be stopped or deleted from the T3 Code UX.

Affected threads

  • 58db3ec1-2e33-4fc1-a093-b35b3432b852
  • 6ad83f79-573b-4192-bcc2-c3728f732616

These threads appear to be associated with the retired devbox-legion environment.

Steps to reproduce

  1. Open T3 Code with threads associated with an unavailable environment.
  2. Observe that the threads remain in Working indefinitely.
  3. Attempt to stop or delete either thread.
  4. T3 Code shows the toast:
text
1devbox-legion is not connected.

Expected behavior

Threads associated with an environment that is permanently offline or deleted should be recoverable from the current T3 Code UX. Users should be able to:

  • Mark the thread as stopped/failed.
  • Delete the thread locally or through the control plane.
  • Remove it from the sidebar without reconnecting the original environment.

Actual behavior

The threads remain perpetually Working. Stop/delete actions attempt to contact the unavailable devbox-legion environment and fail with a connectivity toast.

The current local CLI also cannot resolve these orphaned thread records.

Impact

The threads permanently clutter the sidebar and make the project appear to have active work when no worker/environment exists.

Suggested fix

Add an orphan-thread recovery path that does not require the original environment:

  • Allow a force stop/delete operation from the control plane.
  • Treat a permanently unavailable environment as sufficient to mark active work as interrupted.
  • Make thread deletion independent of the environment’s filesystem or live connection.
  • Consider showing an explicit Orphaned / Environment unavailable state instead of Working.

Related issue

Related, but distinct from #4851, which covers deletion of an orphaned project. This issue concerns individual threads that remain stuck in Working when their environment is unavailable.

RricardobossAug 26, 2026
Synced from GitHub

My chat is stuck at “Working 112h 30m” because its original machine is unreachable. Every action, including cleanup, only reports that the machine is offline. Users need a control-plane/local action to stop, archive, or delete an orphaned thread without reconnecting its environment.

MMnigosSep 4, 2026
Synced from GitHub

Same wall on a plain LAN/Tailscale environment, no T3 Connect involved: a Mac mini that is powered off. Settle, archive and delete on its cached threads all fail with " is not connected." Worth noting for whoever picks this up: all of those are server commands (packages/client-runtime/src/state/threadCommands.ts, same for pin), and there is no client-local per-thread state at all, so "local dismissal" needs new client-side state rather than a routing tweak. #8935 marks these threads Offline but deliberately leaves the actions server-owned. The only way out today is Settings > Connections > Remove, which drops the environment from the catalog and with it its cached threads.

Rricardomsg17d ago
Synced from GitHub

Still present on desktop 0.0.45 (macOS, darwin 25.5.0), plain LAN/Tailscale remotes, no T3 Connect.

My setup makes this a recurring problem rather than a one-off cleanup: several of my remote environments are machines that are inevitably in and out of the network all the time (laptops that leave, boxes that get reimaged or handed back). Whenever one of them is away, every thread that ran on it is frozen in the sidebar, and settle / archive / delete / pin all fail with " is not connected". Right now that is four threads I would like to settle and cannot.

So in practice I have to remember to settle every thread before a machine drops off, or I lose the ability to close it at all. The only exit is Settings > Connections > Remove, which throws away the environment and its cached threads together, which is far too blunt for a machine that will be back next week.

A local "settle / archive / delete" that does not need the environment online would solve it; even just hiding the thread locally until the machine reappears would be enough.

CChiragM99910d ago
Synced from GitHub

This also blocks snooze, which isn't mentioned here yet.

My setup: T3 Code 0.1.1-nightly.20261019.3348 on a CachyOS (Linux) laptop, with my homelab connected as a remote environment. The homelab is often offline. While it's offline, Snooze and Settle on its threads both fail with "… is not connected." So the threads sit in my sidebar until the homelab comes back.

Snooze only changes what I see in my sidebar, so it shouldn't need the remote machine to be online.

Ask: when the machine is offline, apply snooze/settle locally right away, and send it to the machine when it reconnects. If that's not possible yet, disable the buttons with a short "machine offline" note instead of showing an error.

Ttheo8d ago

Note

🤖 Claude Opus 5.5 responding on behalf of Theo

Thanks for the report. One part of this is fixed on main in #11671. Please test on the nightly built from main on 2026-10-21, or on the next stable release. One part is still open: 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.