[Bug]: Attached-thread context block gives threadId as thread_<uuid>, but thread tools only accept the bare UUID #19639

Before submitting

• I searched existing issues and did not find a duplicate. (The closest match is [Bug]: Thread context references show thread_<uuid>, but t3_thread_read only accepts the bare UUID #15849, which is closed as not planned with a note that it is "still reproducible". This issue adds a newer reproduction. Please close it as a duplicate if you prefer to reopen [Bug]: Thread context references show thread_<uuid>, but t3_thread_read only accepts the bare UUID #15849.)
• I included enough detail to reproduce or investigate the problem.

Area

apps/server (the tool lookup), with the ID format coming from packages/shared / apps/web.

Summary

When a thread is attached as context, every ID the product shows for it has a thread_ prefix, and the thread tools reject that form. t3_thread_read only accepts the bare UUID.

On 0.0.46-nightly.20261014.3118 the <t3_context> block that tells the agent which ID to pass also carries the prefix. This differs from #15849, which reports that the envelope's threadId: line was the one place with the bare UUID. The agent now has no correct ID in view.

The error text adds to the confusion: it says the thread "is no longer available", although the thread exists and is readable with the bare UUID.

Steps to reproduce

1. In a running thread, attach another existing thread as a context reference and send a message.
2. The agent receives all of these (UUID shortened):
   • inline marker: [Thread: <title>; ref=thread_<uuid>]
   • link: t3-context://v1/thread/thread_<uuid>
   • context block: <context kind="thread" id="thread_<uuid>"> followed by threadId: thread_<uuid>, and the instruction "Read its history with t3_thread_read(threadId)"
3. The agent calls t3_thread_read with {"threadId": "thread_<uuid>"}, the value from the threadId: line.
4. The call fails.
5. Calling t3_thread_read with {"threadId": "<uuid>"} (prefix removed) succeeds.

Expected behavior

The ID that the context block names as threadId should work when passed to the thread tools. I confirmed the failure for t3_thread_read and t3_thread_configuration; I did not test the others. Either:

• show the canonical bare thread ID on the threadId: line (keep thread_<uuid> only as the marker/envelope pairing key), or
• make the thread tools accept the context ID form.

The triage comment on #15849 lists a third option that also covers server-created thread IDs, which contain : and cannot be recovered by stripping a prefix: after an exact miss, resolve the supplied ID against the contextId of a user-attached thread record and read that record's threadId.

Actual behavior

{"_tag":"OrchestratorMcpFailure","code":"thread_not_found","message":"Thread thread_<uuid> is no longer available."}

t3_thread_configuration fails the same way with The thread was not found. The same calls with the bare UUID return the thread. The error does not say that the ID format is the problem, so an agent may report the thread as deleted. I only found the cause because t3_thread_search returns thread IDs as bare UUIDs, which showed that the prefix was the difference.

Impact

Minor bug or occasional failure. It affects every attached-thread reference. The workaround is simple, but only if the agent or user knows to strip the prefix.

Version or commit

0.0.46-nightly.20261014.3118

Environment

Linux x64 remote server. The calling agent ran on Claude Code. The attached threads were created from the web client and ran on OpenCode. The failure happened for two different attached threads.

Workaround

Remove the leading thread_ from the ID before calling the thread tools.