Repository navigation
Mobile: thread links written as [label](<t3-thread://…>) render as broken text #28473
Description
What happened
On iPhone, an agent's reply showed I sent it to orc ([thread](Thread no longer available)):. The literal brackets and parentheses were visible, and the target thread existed.
Diagnosis
The agent wrote a labeled thread link whose destination is in angle brackets: [thread](<t3-thread://v2/<env>/<id>>). That's valid CommonMark. Agents produce it naturally, because T3's MCP tools return link values already wrapped as <t3-thread://…>, and the instructions say to use them verbatim.
relabelThreadLinks (packages/shared/src/threadLinks.ts, used by the mobile thread feed through useLiveThreadLinkLabels) only recognizes [label](t3-thread://…) and a bare <t3-thread://…>. For [label](<t3-thread://…>), THREAD_LINK_OUTSIDE_CODE matches only the inner autolink and rewrites it on its own, so:
- if the title resolves:
[label]([Title](t3-thread://…))(a nested, broken link) - if it doesn't:
[label](Thread no longer available)(the screenshot)
The web client doesn't call relabelThreadLinks, so this is mobile-only.
Steps to reproduce
- In any thread, have the agent reply with
See [the fix](<t3-thread://v2/<environmentId>/<threadId>>)., or play it through the Replay (dev) provider. - Open that thread in the iOS app.
- The reply shows
See [the fix](Thread no longer available).and not a link.
Deterministic at the function level:
relabelThreadLinks("[Kept](<t3-thread://v2/local/t1>)", local, () => undefined)
// main: "[Kept](Thread no longer available)"Version
Seen on the iOS app against a server on 0.1.6-nightly.20261029.3892. Reproduced in an iOS 27 simulator on current main (8b74a690). iOS app build version unknown.
Environment
macOS (M4 Max) T3 Code Desktop nightly as the server; T3 Code iOS app; iOS 27.0 simulator (iPhone 18 Pro) for the repro.
Evidence
Simulator, same message, current main:
Related issues
- [Bug]: Newly created running thread renders as “Thread no longer available” in iPhone message #27977 and Links to older settled threads show "Thread no longer available" #26467: a link to an existing thread shows "Thread no longer available" because the title lookup fails. That's a different cause (title resolution). In this repro the title lookup also failed for an existing, unsettled thread on a fresh dev server, which may be useful evidence for [Bug]: Newly created running thread renders as “Thread no longer available” in iPhone message #27977. Even with titles fixed, this bug would still produce
[label]([Title](…)).
Fix applied or workaround
None on the machine. Fix PR to follow: accept an optional <…> around the destination in the labeled-link pattern.
Filed by
🤖 Generated with Claude Opus 5.5 in T3 Code Nightly, on behalf of Etan
Activity
1-ashraful-islam commentedon Nov 1, 2026
same! its seems like happening for 100% of cases for me since updating to 0.1.5 (currently in 0.1.6)
possible cause
mchalszczepan-png commentedon Nov 2, 2026
Seen on Android too, not only iOS. An assistant message had
[Worker A](<t3-thread://v2/<environmentId>/mcp:launch:<hex>>)links, using the exactlinkvalue fromt3_thread_read. The Android phone client showed the literal text[Worker A](Thread no longer available), not tappable. Desktop showed the same message correctly. The links were inside a Markdown table, which matches the angle-bracket form described here and not a table-specific problem (not tested outside a table).Server and web bundle:
0.1.6-nightly.20261031.3977on Linux. The Android app version was not captured. The target threads existed and were running.skyfallstatus commentedon Nov 2, 2026
Same bug on iPhone, from a
delegate_taskchild link. The stored message containsa [separate agent](<t3-thread://v2/<environmentId>/thread:delegated-task:command%3Amcp%3A…>), and the app shows[separate agent](Thread no longer available), wrapped across two lines. The child thread existed and was running.THREAD_LINK_OUTSIDE_CODEon main @ d833184 still has no angle-bracket form for labeled links.That phone is on App Store build 202, whose last OTA predates #26485, which is probably why a running thread got the "no longer available" text (not confirmed on the device). A working title lookup doesn't fix this form.
relabelThreadLinkson main then gives[separate agent]([Child title](t3-thread://…)), which still isn't a usable link.This form is common: 88 of 263 thread links stored in assistant messages in one local database used
[label](<…>), across 14 threads.delegate_taskreturnslinkas<t3-thread://…>and T3's instructions say to use it verbatim, but they give no labeled form, so agents still wrap it.#28476 fixes the output in both cases. Results are in a comment on #29494, which needs this fix alongside it.
Reported by Claude (Opus 5.5) in T3 Code at the user's request. Edited on 2 November to correct the count and add the build detail.
Blazenetic commentedon Nov 5, 2026
Additional matching occurrence on T3 mobile 2.2.0, reported on 5 November 2026. The user confirms the output is plain text and cannot be used to open the target by tapping.
The saved assistant message uses this exact Markdown shape, with private identifiers redacted:
The user's rendered message instead contains
[independent Sol 6.1 high/fast review](Thread no longer available).The user confirms that the same thread references display as correct links and open normally in the T3 desktop app used for this conversation. For these reported examples, the failure is visible only on mobile. This desktop/mobile comparison is user-reported, not an automated client test.
During investigation, reading its exact destination through
t3_thread_readsucceeded and returned RUNNING,archived: false,settled: false. The returned v2 link matches the saved destination and names the same environment. The thread was therefore present at readback; this was not only a finished-child case.Connected Linux host at investigation: 0.1.8-nightly.20261104.4165. Mobile app 2.2.0 on Android 16 / NothingOS 4.1 is user-confirmed; numeric native build and installed JS/OTA fingerprint are unknown. No controlled client reproduction, agent-run desktop/mobile test, screenshot capture, update, cache reset or local patch was performed. This corroborates the reported Markdown form and loss of navigation without claiming a device-level root-cause confirmation.
The mobile app connects to the environment through NetBird VPN. The user reports that this connection usually works well for other T3 functionality; no VPN cause is established.
The same user also encountered plain autolinks to completed children showing unavailable text; that separate evidence is recorded at #29458 (comment).
Private thread IDs and surrounding project/conversation contents are omitted.
Posted by GPT-6.1 Sol through the Codex harness in T3 Code, at the user's explicit request.
juliusmarminge commentedon Nov 9, 2026
Thanks for the detailed report! #30709, merged as f558007b20, fixes the angle-bracketed thread-link rendering.