[Bug]: Assistant-generated thread links open a browser instead of navigating within T3 #16194

Before submitting

• I searched existing issues and discussions. Related desktop deep-link tracking is listed below; I did not find a report specifically covering assistant-generated thread links inside chat.
• I included enough detail to investigate the problem.

Area

apps/web, including the desktop app's shared chat renderer.

What happened

When an assistant references another existing T3 thread in a chat reply, the link can be an HTTP URL on 127.0.0.1. Clicking it from T3 desktop opens the system browser instead of selecting that thread inside the app.

Users can already insert an existing thread with @ or drag it from the sidebar into the composer. That produces a thread chip which navigates internally. Assistant replies have no equivalent supported rendering path, making it difficult for an agent to hand the user a useful link after finding or creating a thread.

Steps to reproduce

Reported workflow, with the click-handling path confirmed by source inspection:

1. Open T3 desktop and have two existing threads in a connected environment.
2. In one thread, ask the assistant for a link to the other thread.
3. If it returns a Markdown link to the local web route, such as [Other thread](http://127.0.0.1:<port>/<environmentId>/<threadId>), click it with the system-browser link preference.
4. T3 opens the URL in an external browser rather than navigating to the existing thread.
5. For comparison, attach the same thread using @ in the composer: its thread chip uses internal navigation.

The URL above is a placeholder example, not a captured private thread URL. I have not independently run a fresh GUI reproduction.

Expected behavior

An assistant should have a supported way to reference an existing T3 thread that the user can click to open inside the current client, using the appropriate environment and thread IDs.

Ordinary web links should retain their configured behavior. This report does not propose treating every localhost URL as a T3 thread.

Actual behavior and source diagnosis

Inspected at commit 2188bdd8b5c0251f40daebdb66647dd0150cf076:

• ChatMarkdown's anchor renderer renders ordinary links with target="_blank". It recognizes some special link types, but has no thread-route interception; other links follow the browser preference.
• DesktopWindow forwards safe new-window URLs to openExternal, explaining why the localhost link opens the system browser.
• AssistantTimelineRow does not supply renderContextReference. Emitting a t3-context:// reference in assistant Markdown therefore falls back to a plain text label, not a thread chip. Those references also require attached context records; a context ID is not simply a thread ID.
• ThreadContextChip already navigates through the typed /$environmentId/$threadId route for user-attached threads.

Impact

Minor bug or occasional failure. Agents can find/create threads, but cannot give the user an equivalent clickable in-app reference in their replies. Users must locate the destination manually or attach it themselves.

Version and environment

• macOS, T3 Code desktop nightly, Codex provider.
• Source diagnosis at the commit above. The installed nightly may differ from that checkout.
• Desktop behavior was reported by the user; source inspection covered the shared web renderer and Electron link handling. Mobile was not verified.

Workaround

Find the destination in the sidebar, or type @ plus its title in the composer and use the resulting thread chip. Changing the HTTP hostname alone does not add internal thread navigation.

Related issues and work

• [Bug]: Desktop ignores t3code://threads/… deep links the app itself generates (#4996 closed as completed, never merged) #9745 is open and tracks desktop handling of external t3code:// thread deep links.
• Route t3code:// deep links into the existing thread route #11865 was closed as a duplicate of [Bug]: Desktop ignores t3code://threads/… deep links the app itself generates (#4996 closed as completed, never merged) #9745.
• feat(desktop): open thread deep links via t3code:// #8246 is open and unmerged. Its scope is desktop OS deep-link dispatch and renderer routing; it does not change assistant Markdown link rendering.
• This comment on #4996 explicitly asks for clickable thread protocol links in chat.

The distinction is the entry point: this report concerns references rendered inside assistant chat messages. An OS-level deep-link handler alone would still leave the Markdown/reference rendering path to address.

Prepared with GPT-6 Astra through the Codex harness in T3 Code.