# Opening an archived thread by its link sends you back to the home screen · Issue \#16443 · pingdotgg/t3code

[View on GitCafe](https://git.cafe/pingdotgg/t3code/issues/16443)

Repository: [pingdotgg/t3code](https://git.cafe/pingdotgg/t3code)

Visibility: public

State: backlog

Priority: 0

## Description

[Discussion and activity](https://git.cafe/pingdotgg/t3code/issues/16443)

---

## Observed

The command palette lists a pull request's archived threads as "Archived thread", and the thread relationships control lists archived related threads. Both navigate to `/$environmentId/$threadId`. For an archived thread, that route never shows the conversation: it redirects to `/` (or shows an empty pane when the environment has no other threads). Pasting an archived thread's URL behaves the same way.

## Reproduction

1. Create a thread, send a message, then archive it.
2. Open it from the command palette's linked-thread list for its pull request, or from a related thread's relationships control, or paste its `/$environmentId/$threadId` URL.
3. The app returns to the home screen instead of showing the thread.

## Cause

- The shell snapshot the web client keeps holds active threads only; archived ones live in a separate archive snapshot. So `useThreadShell` returns `null` for an archived thread.
- `ThreadRouteView` treats a missing shell after bootstrap as `missing` (`resolveThreadRouteRenderState`), does not mount `ChatView`, and its cleanup effect navigates to `/`.
- Even if `ChatView` were mounted, it uses that same shell as its active thread and renders the empty state without it.

The server can serve the thread: `/api/orchestration/threads/:threadId` (`getThreadSnapshot`) and the thread subscription do not filter archived threads, and a truly absent id comes back as not found, which the client turns into status `deleted`.

## Expected

An archived thread opened by its link shows its conversation. A thread that does not exist or was deleted still leaves the route as today.

## Environment

macOS, T3 Code main at 9bd1d8009a. Found from code reading and a unit-level reproduction (shell atoms with an archived thread, then the route's render state) that resolves `missing`.

## Proposed direction

While the active shell lacks the target, keep the route loading and mount the chat so the thread detail loads; treat the route as missing only once the detail reports `deleted`. The chat then needs a shell for the archived thread, either from the archive shell snapshot (`orchestrationEnvironment.archivedShellSnapshot`) or by deriving it from the loaded detail (the server's `threadShellFromProjection` would have to move to a shared package). Which source to use is a maintainer choice.

I haven't written a fix, because the shell source is a design choice.

Found while porting fixes from a downstream fork (Scient). Investigated with Claude Opus 5.5 in Claude Code.