# \[Bug\]: Thread context references show thread\_\<uuid\>, but t3_thread_read only accepts the bare UUID · Issue \#15849 · pingdotgg/t3code

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

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

Visibility: public

State: canceled

Priority: 0

## Description

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

---

### Before submitting

- [x] I searched existing issues and did not find a duplicate.
- [x] I included enough detail to reproduce or investigate the problem.

### Area

apps/server

### Summary

When a user attaches a thread as context, the provider prompt renders an inline marker `[Thread: <title>; ref=thread_<uuid>]`, and the stored message keeps the link `t3-context://v1/thread/thread_<uuid>`. The thread-scoped MCP tools resolve `threadId` by exact lookup, so an agent that copies the ID from the marker or link fails. Only the bare UUID carried in the injected `<t3_context>` envelope (`threadId: <uuid>`) works.

On the current build the failure is masked by #15566 as an output-schema error, so the agent cannot tell it is an ID-format problem. In a live session I watched the agent fail with the prefixed ID and recover only after stripping the prefix on retry.

### Steps to reproduce

1. In a running thread, attach another thread as context (composer context chip) and send the message.
2. As the agent, call `t3_thread_read` with the ID exactly as displayed in the reference — the `ref=` value in the marker, or the last path segment of the `t3-context://v1/thread/...` link:

   ```json
   {"threadId": "thread_<uuid>"}
   ```

3. The call fails. With #15566 unfixed this surfaces as:

   ```
   Structured content does not match the tool's output schema: data must have required property 'thread', data must have required property 'recentRuns', ...
   ```

   The server trace for the call shows the failed lookup:

   ```
   McpServer.@effect/mcp/2025-06-18/tools/call tool=t3_thread_read parameters={"threadId":"thread_61431f2f-5a89-4dc9-8d6d-a2a357d20238"} exit=Success
   sql.transaction exit=Failure cause=ProjectionStoreThreadNotFoundError: No orchestration projection exists ...
   ```

4. Call again with the bare UUID from the envelope's `threadId:` line and it succeeds.

### Expected behavior

The reference ID form the product displays should be accepted by the tool the injected context tells the agent to use, or the reference should display the canonical bare thread ID. Accepting both forms server-side (normalizing a leading `thread_`) seems least disruptive, because the marker `ref` is also the pairing key for the `<t3_context>` envelope entry while the payload already carries the bare `threadId`.

### Actual behavior

`t3_thread_read({threadId: "thread_<uuid>"})` fails with `thread_not_found` (masked as the #15566 schema error). `t3_thread_read({threadId: "<uuid>"})` succeeds.

Relevant code:

- `packages/shared/src/composerContextReferences.ts:121-131` — the provider marker emits `ref=<contextId>`.
- `packages/shared/src/composerContextReferences.ts:236-242` — the thread payload carries the bare `threadId`.
- `apps/web/src/lib/composerContextReferences.ts:55-70, 160-180` — thread context ids are built as `thread_<uuid>`.
- `apps/server/src/mcp/OrchestratorMcpService.ts:849-875` — `loadReadableThread` does an exact lookup, and the attached-thread fallback set stores bare ids, so the prefixed form never resolves.

### Impact

Minor bug or occasional failure, but it affects every attached-thread reference for agents that copy the visible ID. The intended path works, so this is a discoverability/robustness trap rather than a hard block.

### Version or commit

0.0.46-nightly.20261004.2657 (live reproduction); source inspection on current `main`.

### Environment

macOS, T3 Code desktop nightly, provider opencode (opencode-go).

### Logs or stack traces

```shell
McpServer.@effect/mcp/2025-06-18/tools/call tool=t3_thread_read parameters={"threadId":"thread_61431f2f-5a89-4dc9-8d6d-a2a357d20238"} exit=Success
sql.transaction exit=Failure cause=ProjectionStoreThreadNotFoundError: No orchestration projection exists ...
```

### Workaround

Pass the bare UUID from the `<t3_context>` envelope instead of the displayed `ref`.