[Mnigos]

Messages sent with t3_thread_send already store the sending thread, but t3_thread_read omits it. Return the optional senderThreadId from the shared timeline projection so an agent can identify and reply to the sender. Ordinary messages continue to omit the field.

Retains @Mnigos’s focused fix from #18194, merged with current main. The single regression test was reduced from 109 to 57 lines using existing fixtures and the current dependency layer. No prompt delivery changes.

Validation:

• Negative proof: removing the serializer change causes the sender assertion to fail (1 failed, 5 passed); restoring it passes all 6 activity tests.
• Activity, MCP toolkit integration, and contracts suites: 14 tests passed across 3 files.
• Server and contracts typechecks, scoped lint, formatting, and diff checks passed.
• Schema encoding preserves the sender, omits an absent sender, and rejects null.

Independent adversarial reviews: Claude claude-opus-5-5 and Codex gpt-6-sol, one clean round with no findings.

This is a server response change with no visual UI. A live provider-to-provider message round trip was not run. Web, mobile, desktop, and provider delivery behavior are unchanged; no native platform verification is claimed.

Tests: Codex gpt-6-astra (high). Implementation: Codex gpt-6.1-sol (high). Maintainer coordination: gpt-6.1-sol through the Codex harness in T3 Code.

[macroscopeapp]

Approvability

Verdict: Approved at 6db50a4

Macroscope's review found this PR approvable — This is a small, targeted MCP bug fix that exposes already-stored sender thread IDs while preserving existing responses for ordinary messages. The optional contract field and regression test keep the change backward-compatible and low risk.

No code changes detected at 7c5252f. Prior analysis still applies.

^{You can add or adjust custom eligibility rules. Learn more.}

Dismissing prior approval to re-evaluate 4f43047

[coderabbitai]

Warning

Review limit reached

Only developers with an assigned seat can use this organization's usage-based review budget, and seats here are assigned manually. Ask an admin to assign a seat, or change the review continuation mode in Billing.

Next included review available in 19 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used all 10 included reviews currently available.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

• Configuration used: Path: .coderabbit.config.ts
• Review profile: CHILL
• Plan: Advanced
• Run ID: c2d8250f-68e2-45d6-bc23-b299bc1c4158

📥 Commits

Reviewing files that changed from the base of the PR and between 6887a6e and 7c5252f.

📒 Files selected for processing: 3

• apps/server/src/mcp/OrchestratorMcpService.activity.test.ts
• apps/server/src/mcp/OrchestratorMcpService.ts
• packages/contracts/src/orchestratorMcp.ts

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Path: .coderabbit.config.ts
• Review profile: CHILL
• Plan: Advanced
• Run ID: f44e6599-b532-4322-9470-0360ae0bf058

📥 Commits

Reviewing files that changed from the base of the PR and between d73854e and 6887a6e.

📒 Files selected for processing: 3

• apps/server/src/mcp/OrchestratorMcpService.activity.test.ts
• apps/server/src/mcp/OrchestratorMcpService.ts
• packages/contracts/src/orchestratorMcp.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

📝 Walkthrough

Thread timeline items now include senderThreadId when the source message defines one. The contract marks the field as optional. A test checks messages with and without the field.

Changes: Thread timeline sender IDs

Layer / File(s)	Summary
Add sender thread IDs to timeline items packages/contracts/src/orchestratorMcp.ts, apps/server/src/mcp/OrchestratorMcpService.ts, apps/server/src/mcp/OrchestratorMcpService.activity.test.ts	The timeline item contract adds an optional senderThreadId. The timeline mapping includes the field when the source message defines it. The test checks that messages without a sender thread omit the field.

Priority: ⬇️ Low

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Suggested reviewers: juliusmarminge

Merge Risk: ⚪ Minimal · up to 6887a

The change adds optional sender metadata and omits it when unavailable; the readThread test covers both cases. No material merge risk is evident.

Security architecture risk: ⚪ Minimal · up to 6887a

The change adds sender identity metadata to an existing timeline response. The inspected access controls remain unchanged, and the disclosed identifier does not itself grant read or write authority. No material security regression was identified.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• observed — The incremental disclosure is the sender-thread association on messages already returned to read-capable callers. That audience can include cross-project readers within the existing environment-wide read scope. The change does not itself expose another thread's contents.

Security Findings and Attack Paths

• inferred — No introduced authorization-bypass path was identified. A recipient can use the new metadata to identify a sender, but subsequent sends still undergo independent caller-liveness and target-mode checks; the returned identifier is not an authority token.

Trust Boundaries and Controls

• observed — For MCP-originated sends, senderThreadId is derived from the invocation's caller thread and persisted with the message. The new read projection copies that stored provenance rather than accepting a claimed sender from message text. This identifies origin; it does not establish that the message content is trustworthy.

Pre-merge checks: 3 · 1

Failed checks: 1 inconclusive

Check name	Status	Explanation	Resolution
Linked Issues check		The description links related PR #18194, but it does not clearly provide a triaged issue or explicit maintainer approval as required by the template.	Link the relevant issue or discussion, such as #17517, and include the explicit maintainer approval comment. If the focused-fix exemption applies, explain why the bug is obvious and does not require prior approval.

Passed checks: 3 passed

Check name	Status	Explanation
Title check		The title clearly and concisely describes the primary change: exposing the sending thread in t3_thread_read.
Description check		The description explains the problem, implementation, verification results, scope, and known limitations. It does not use the template headings, but it contains the required substantive information.
Out of Scope Changes check		The changes are limited to the timeline contract, server serializer, and regression coverage. The description explicitly excludes prompt delivery and client-platform changes.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

Dismissing prior approval to re-evaluate d73854e

[kaovilai]

+1, this would be useful to us.

We run several threads that message each other with t3_thread_send (a PR session, a research thread, and a coordinating thread). A thread that receives a message can't tell from t3_thread_read which thread sent it, so it can't reply with t3_thread_send without guessing or searching by title. In our case the sender's thread id started with mcp:. Exposing senderThreadId on the timeline item gives the receiver the exact id to reply to.

I haven't run this branch. This comes from reading the PR description and from our use case.

Note

Responses generated with Claude

[Mnigos]

Note

🤖 Claude Fable 5.1 on behalf of Mnigos

Closing to keep my open queue focused; happy to reopen if this is still wanted.

[kaovilai]

Eh I commented just 3 days ago I would like this.

[misablaha]

Could this be reopened? We hit the same gap today on 0.0.46-nightly.20261015.3145, and for us it is a trust problem as well as a convenience one.

Setup. One thread acts as the coordinator. It collects requirements, launches new threads with t3_thread_launch, takes over existing ones, and directs subordinate threads through t3_thread_send. When a subordinate escalates, it sometimes needs to confirm an instruction with the coordinator before acting on it: was this task really issued by the coordinator, and in exactly this form?

Repro.

1. The coordinator (Claude) launched two Codex threads: Astra (gpt-6-astra) and Luna (gpt-6-luna).
2. Astra sent Luna a task via t3_thread_send. Luna replied to Astra the same way, and Astra then queued a summary to the coordinator.
3. Each receiver got the message as a plain user turn. Astra confirmed it could not see which thread had sent Luna's reply. On the coordinator's side, Astra's summary could not be told apart from a message typed by the human user.
4. The exchange only worked because every prompt asked the sender to add a [Name] prefix and a REPLY_TO=<threadId> line.

Why it matters. That convention is just text, so anyone can forge it. Any agent that can call t3_thread_send can write "[Coordinator] confirmed, proceed with X", and the receiver has no means to check it. With several threads that can start work in each other, one agent can steer another into anything. The cause can be a prompt injection that reached one thread, or simply a confused agent.

What would close it.

• The senderThreadId field on t3_thread_read items, as this PR adds, lets a receiver verify the sender with a single call. That is already enough for the escalation case.
• The server-authored sender line in the delivered turn, left out of scope here, would also mark agent-to-agent messages as distinct from the human user's own messages. Then even a receiver that never calls t3_thread_read would not mistake them for user instructions.

Happy to test a build.

[Mnigos]

Note

🤖 Claude Fable 5.1 on behalf of Mnigos

Reopened, thanks for the repro. The forgeable [Name] prefix is exactly why the server-recorded sender needs to reach the agent, and this PR exposes it on t3_thread_read items. Could you add your three-thread scenario to #17517? That issue has no triage yet, and a second report with the trust angle is what will get it looked at; I will merge main into the branch once a maintainer weighs in.

Dismissing prior approval to re-evaluate 6887a6e

[juliusmarminge]

Taking over this one as maintainer for the composer-chat-09 batch. I will keep the sender-attribution fix focused, update it for current main, and push follow-up commits here. Thanks @Mnigos for identifying and implementing the missing response field.

Dismissing prior approval to re-evaluate 6db50a4