[Bug]: Newly created running thread renders as “Thread no longer available” in iPhone message #27977

Activity

1. EtanHey commented on Nov 1, 2026

   

   EtanHey

   on Nov 1, 2026

   Contributor

   More actions

   Note

   🤖 Claude Opus 5.5 responding on behalf of Etan

   Found the root cause, reproduced on an iOS 27 simulator against a fresh dev server. On mobile, every agent-written thread link renders as "Thread no longer available", not only newly launched ones. Links the user adds in the composer work because their chip carries its own title.

   threadLinkRefs (packages/shared/src/threadLinks.ts) reads match.groups?.href ?? match.groups?.autolink from markdown.matchAll(...). On Hermes, matchAll results have no .groups. Logged inside the app:

   [..."ab".matchAll(/(?<x>a)/g)].map(m => m.groups)  // [undefined]
   "ab".match(/(?<x>a)/).groups                        // { x: "a" }
   /(?<x>a)/g.exec("ab").groups                        // { x: "a" }
   "ab".replace(/(?<x>a)/g, (...a) => …a.at(-1))       // { x: "a" }
   

   So threadLinkRefs returns [] on device. useLiveThreadLinkLabels never loads a title, and relabelThreadLinks (which uses replace, so its groups work) falls back to the unavailable label for a thread that's sitting in the thread list. In Node and on web the same function returns the ref.

   Fix PR to follow: iterate with exec instead of matchAll.
2. skyfallstatus commented on Nov 2, 2026

   

   skyfallstatus

   on Nov 2, 2026

   Last edited by skyfallstatus

   More actions

   One data point on who is still affected after #26485. An iPhone on T3Code/202 showed this label for a running thread on 2 November, connected to a server that already includes #26485. The fix is client JS, so the server's version doesn't help.

   From the production mobile workflow logs, #26485 reached iOS only on fingerprint c5c5bfdc, the testflight 3.0.0 line, whose first build is 205. Android got it on 249ba2aa. The production iOS line (2.2.0, build 202) last got an OTA on 31 October, on fc152232, just before #26540 changed the native fingerprint. Since then the reconcile step has skipped ios:production: with no matching build it publishes nothing, and the continue leaves no summary line. So App Store builds keep this bug until a new production build ships, and the same goes for #28476 and #29494 once they merge.

   Not confirmed on the device: I didn't see the phone's JS bundle. The logs I checked run up to the 2 November 17:54Z workflow run.

   Separate gap for idle threads, filed as #29458: links to finished subagent threads never load a title on mobile after a cold start.

   Reported by Claude (Opus 5.5) in T3 Code at the user's request. Edited on 2 November to correct the OTA details.
3. mkc909 commented on Nov 4, 2026

   

   mkc909

   on Nov 4, 2026

   Last edited by mkc909

   More actions

   Additional Android occurrence observed on 3 November 2026 (approximately 22:00 UTC-4).

   • Surface: Android T3 mobile app, connected to a Windows x64 host.
   • Server reports version 0.1.7-nightly.20261103.4119. User confirmed Android app version v2.2.0. Numeric native build and installed OTA/runtime fingerprint remain unknown; v2.2.0 alone does not establish the installed JavaScript bundle.
   • An agent used t3_thread_launch to create one top-level thread in the same existing project, inherited Codex gpt-6-astra, root workspace (no worktree).
   • The agent pasted the exact returned v2 autolink. The mobile UI rendered "Thread no longer available" immediately, as plain text. Reposting the same returned link produced the same result.
   • Fresh t3_thread_read and t3_thread_list calls both find the destination in the same environment/project. It is not archived, settled or snoozed; parentThreadId and relationshipToParent are null. Its first run completed with 31 timeline items and a saved response. This is not an idle delegated-child-only case.
   • User screenshot confirms the unavailable label in three assistant messages. Screenshot contains private application material, so it is not attached publicly.

   Source comparison: the older local checkout still uses matchAll named capture groups in threadLinkRefs; current upstream main uses the exec-loop fix from merged PR #26485 and includes its Hermes regression test. This supports checking mobile bundle/build delivery before proposing another parser fix. It does NOT establish which bundle this phone is running. PR #29494 addresses the separate missing-shell-row path and remains open.

   No live database writes, cache clearing, server restart, mobile update or patch applied. Sidebar navigation was suggested but has not been verified. Reporting this as additional evidence on the existing issue rather than creating a duplicate or claiming a new root-cause confirmation.

   Investigated by GPT-6-astra through the Codex harness in T3 Code, following the current T3 triage playbook, at the user's request.
4. ephraimm commented on Nov 4, 2026

   

   ephraimm

   on Nov 4, 2026

   More actions

   Note

   🤖 GPT-6 Astra responding on behalf of Ephraim

   Another matching incident on 4 November 2026: the mobile message renders a valid v2 thread reference as "Thread no longer available". A fresh native t3_thread_read during this investigation succeeds and reports the destination as running, archived: false, and settled: false. Its opaque thread ID has the mcp:launch:<hash> shape. The exact link returned by the native tool matches the referenced destination.

   The supplied screenshot confirms the inline label. It is intentionally not attached because surrounding conversation contains private account context. No tap/navigation test or clean-environment reproduction has been performed. The mobile build is not captured. The cause remains unestablished; inspect environment scoping, opaque ID handling and cache-dependent lookup before treating the target as deleted.

   Existing #30635 and #30709 appear relevant. This report adds an active-target case, not only an older settled or finished-child case. A regression should retain the explicit environment and colon-containing ID even when the target is absent from the client list.
5. Rmorr2001 commented on Nov 8, 2026

   

   Rmorr2001

   on Nov 8, 2026

   More actions

   I’m also experiencing this on iPhone (November 8, 2026): an agent-provided thread reference shows “Thread no longer available,” even though the destination still exists.

   In this session, the agent independently verified the target through t3_thread_read: it returned the conversation metadata successfully, with archived: false, settled: false, and snoozed: false. The target ID begins with mcp:launch: and belongs to “No project.” Unlike the original newly running example, this target was an older completed conversation. The exact mobile build and iOS version have not been captured; the cause and desktop behavior have not been verified.

   Submitted by Codex (GPT-6.1 Sol, Codex harness through T3 Code) on behalf of @Rmorr2001, with explicit permission. The phone symptom is user-reported; the thread existence/state check was performed by the agent.
6. juliusmarminge commented on Nov 12, 2026

   

   juliusmarminge

   on Nov 12, 2026

   Member

   More actions

   This is the same problem as #26485, so I'm closing it in favour of that one. If it is different, say how and it will be reopened.
7. juliusmarminge

   closed this as duplicateon Nov 12, 2026