fix(server): run_scheduled_task_now returns the thread the run launched

[sbansal1999]

Problem

run_scheduled_task_now returns threadId: null for scheduled tasks that launch a fresh thread per run: unbound tasks, created with bindToCurrentThread=false or scheduled into another project. The handler returned task.threadId, which is the task's bound thread. So the caller can't tell which thread the run created, and can't t3_thread_wait on it, read it, or link it. t3_thread_list doesn't expose scheduledTaskId, so there's no reliable way to find it afterwards.

Expected: the tool returns the thread the run posted to or launched. For a bound task that's the bound thread. For a fresh-thread task it's the thread the run created.

Change

• runTask in ScheduledTaskService now returns { task, threadId }, where threadId is the bound thread or the thread ThreadLaunchService.launch created (null if the launch failed). runNow passes it through.
• The MCP handler returns it in the existing threadId field. The tool's output schema and packages/contracts are unchanged; only the server-side runNow type gained threadId.

Scope and approval

There's no prior issue. This is a small fix for an obvious bug: the tool's threadId output never carried information the caller didn't already have. For bound tasks it echoed the known binding, and for fresh-thread tasks it was always null. The closed #8731, which first proposed this tool, meant it to return the launched thread's identity. The change is limited to the server's scheduled-task service and this one MCP tool, with no client or contract changes.

Verification

• ThreadLaunchService.test.ts now asserts that runNow returns the thread the run posted to, for new-thread and bound-thread tasks (each with user- and agent-created tasks).
• With the fix reverted, those 4 cases fail: expected undefined to equal 'thread:project:…' for new threads and expected undefined to equal 'thread:existing' for bound threads. With the fix, they pass.
• vp test run on ThreadLaunchService.test.ts plus src/scheduledTasks/ (8 files, 107 tests), and on OrchestratorMcpToolkit.integration.test.ts and ClaudeAutomaticDelivery.integration.test.ts (2 files, 5 tests): all pass.
• apps/server typecheck: no errors.
• Not checked: calling the tool against a live server.

Implemented by Claude Opus 5.5 via Claude Code in T3 Code.

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Approved at 07cb1a7

Macroscope's review found this PR approvable — This is a contained scheduler bug fix that propagates the actual launched thread ID through an existing response field without changing task execution, schemas, defaults, or deployment behavior. Existing bound-thread, failure, scheduled, and webhook paths remain accounted for, with coverage for new and existing threads.

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

[coderabbitai]

Important

Review skipped

Review was skipped as selected files did not have any reviewable changes.

⚙️ Run configuration

• Configuration used: Path: .coderabbit.config.ts
• Review profile: CHILL
• Plan: Advanced
• Run ID: e063e8b7-e1ff-46b3-8bb1-889f23c0dccf

---

📥 Commits

Reviewing files that changed from the base of the PR and between 07cb1a7 and e16fab3.

---

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

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: 12b92b92-7d1a-4dff-a66a-ae93af5aa530

---

📥 Commits

Reviewing files that changed from the base of the PR and between 101f8b2 and 07cb1a7.

---

📒 Files selected for processing (3)

• apps/server/src/mcp/toolkits/thread/handlers.ts
• apps/server/src/orchestration-v2/ThreadLaunchService.test.ts
• apps/server/src/scheduledTasks/ScheduledTaskService.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

Walkthrough

Scheduled task runs now return a threadId alongside the task. The result includes the bound thread ID or the launched thread ID, and returns null when no thread is dispatched or launch fails. The manual-run handler and MCP response use this value.

Changes

Scheduled task run results

Layer / File(s)	Summary
Resolve the thread ID for each run apps/server/src/scheduledTasks/ScheduledTaskService.ts	runTask returns the task with a threadId. It uses the bound thread ID or the launched thread ID on success, and null when the run does not dispatch or launch fails.
Return and consume the run result apps/server/src/scheduledTasks/ScheduledTaskService.ts, apps/server/src/mcp/toolkits/thread/handlers.ts, apps/server/src/orchestration-v2/ThreadLaunchService.test.ts	The manual-run handler returns the run result directly. Webhook handling reads the task from the result. The MCP handler uses the result’s threadId, and a test checks it against the selected project thread.

Priority: ⬇️ Low

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

Change: Bug fix

Suggested reviewers: juliusmarminge

---

Merge Risk

Merge Risk: ⚪ Minimal · up to 07cb1

Scheduled task runs now report the thread they posted to or launched, and the MCP tool returns it. No concrete merge-blocking issue was found.

Security Architecture Review

Security architecture risk: 🔵 Low · up to 07cb1

Authorized callers now receive the thread actually used by a scheduled run. No weakened access control was identified. Remaining uncertainty concerns other response paths and the consistency of returned task information during concurrent updates.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — The identifier can facilitate follow-up access to a launched thread in another project within the same server environment. Environment-wide ID targeting already exists; the change improves target discovery rather than introducing a new authorization primitive.

Trust Boundaries and Controls

• observed — The tool remains behind writesEnvironment. Its existing checks reject read-only clients, validate live thread callers and require full-access runtime mode with default interaction mode before invoking the handler.

Resilience and Maintainability Implications

• observed — The inspected transition retains per-task reservation, stale-row checks, dispatch failure capture, guarded terminal bookkeeping, best-effort stuck-run release and unconditional reservation cleanup. The PR changes returned values rather than these failure-containment mechanisms.

---

---

---

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.
Title check		The title clearly and concisely describes the primary fix: returning the thread launched by run_scheduled_task_now.
Description check		The description covers the problem, expected behavior, implementation, scope rationale, verification results, unverified live-server testing, and agent attribution. It explains why no issue link is re…

---

---

✨ 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.}