[SouthCarpet]

claude-sonnet-5-5 on behalf of SouthCarpet

Problem

When a scheduled task's run starts but its dispatch fails, run_scheduled_task_now replies { taskId, threadId: null, lastRunStatus: "failed", runCount, nextRunAt }. The server already stored a reason in task.lastRunError (apps/server/src/scheduledTasks/ScheduledTaskService.ts:1112 and :1132), but the tool's success schema (apps/server/src/mcp/toolkits/thread/tools.ts) has no field for it and the handler (apps/server/src/mcp/toolkits/thread/handlers.ts) does not read it. An agent that calls the tool sees only threadId: null and cannot tell why the run failed.

This is a different gap from #25647. That PR covers a refused call, where the tool returns an error. This PR covers the success path, where the run started and then failed.

Change

• tools.ts: add lastRunError: ScheduledTask.fields.lastRunError to ScheduledTaskRunTool.success. It reuses the existing nullable string field of packages/contracts/src/scheduledTask.ts:261.
• handlers.ts: return task.lastRunError in the reply.

No change to the contracts package, to settings or to who may call the tool.

What text this returns

lastRunError is free text and this PR does not filter it. ScheduledTaskService.ts:1112 stores the result of dispatchErrorMessage (:370-376). For a direct orchestration refusal with a string cause, that is the user-facing text of the refusal when one exists (#32115). In every other case it squashes the failure cause and stores Error.message, or String(failure) for a value that is not an Error (:365-368).

• Most typed errors of the launch and send paths build their message from a fixed template with ids (ThreadLaunchService.ts:134-158, ThreadManagementService.ts:219-371). One exception: ThreadManagementWorktreeRestoreError (ThreadManagementService.ts:326-337) puts the message of its cause into its own message.
• OrchestratorCommandPreviouslyRejectedError (Orchestrator.ts:339-350) adds a free-text detail taken from a stored receipt error.
• An unexpected throw is stored as its raw message. ScheduledTaskService.webhook.test.ts:1387-1415 shows this on the real service: an injected Error("injected start failure") is stored verbatim.

The same stored field is already rendered to a connected UI user in web settings (ScheduledTasksSettings.tsx:809) and mobile settings (SettingsScheduledTasksRouteScreen.tsx:1579-1581). With this PR the text also enters the context of the calling agent. The tool keeps its existing access policy unchanged (McpToolAccess.writesEnvironment: a full-access runtime and the default interaction mode). I make no claim that the text is sanitized. #29889 removed stack traces from it.

Scope and approval

No prior issue. This uses the route for a very small, focused fix of an obvious bug in CONTRIBUTING.md: two added source lines copy a field that the server already computes into an existing reply. The sibling fix #25647, for the refusal path of the same tool, states the same route in its own "Scope and approval" section, has no closing issue reference, and was merged on 2026-11-01.

Size: 50 changed lines in 3 files. Without the test file, 2 changed lines.

Verification

• New test run_scheduled_task_now reports why a started run failed to dispatch in apps/server/src/mcp/toolkits/core.test.ts. It calls the real tool registration through McpServer.callTool with a mocked ScheduledTaskService. It proves that the reply forwards the stored field. It does not prove what text a real failure stores; the section above covers that by source reading and by the existing webhook test, and the evidence below shows one real failure.
• Mutation check: with the two source lines reverted and the test kept, the test fails at the assertion on lastRunError. With the lines restored it passes.
• vp test run apps/server/src/mcp/toolkits/core.test.ts: 26 passed.
• vp run check:changed e101cae1b9: format, lint, knip, graphql, typecheck (3 packages) and tests pass.
• Overlap: no open or merged PR adds lastRunError to this reply. fix(server): retain scheduled dispatch refusal reasons #32115 (merged 2026-11-15, on this base) changes the content of lastRunError for one case and leaves the MCP schema alone. fix(server): scheduled runs record how their turn ended #23131 (open) adds lastRunError to the list_scheduled_tasks summary and does not change this reply. fix(server): scheduled tasks record runs that fail after dispatch #31366 (closed as a duplicate of fix(server): scheduled runs record how their turn ended #23131) held the same two lines inside a larger change. fix(server): a failed scheduled run shows its error without a stack trace #29889 (merged) is on this base.
• Not run: the evals/mcp-tool-use eval. It calls paid models. Five of its cases mention run_scheduled_task_now; none grades this tool's reply or mentions lastRunError. I added no case.
• No UI surface, so no web screenshots. The evidence below is command output.

Evidence

I started the real server of each commit from source, each with a fresh isolated home and an empty working folder. I made the same run_scheduled_task_now call over the real MCP endpoint with a small HTTP client (pairing code, full access). Setup on both sides: one new project whose default model belongs to the claudeAgent provider, one disabled interval task, then claudeAgent disabled in the settings of that home. The manual run starts and its dispatch fails for a real reason. These are command outputs, not web screenshots.

Before, e101cae1b9 (main): the reply has no lastRunError.

After, 7d73b41f93 (this branch): the reply also has "lastRunError": "Provider instance \"claudeAgent\" is disabled for project mcp:cf653924-…".

On the base side the server holds the reason in its database (last_run_error), but the reply leaves it out.

Not shown:

• A provider session that makes the call. My client called the endpoint directly; the tool code path is the same.
• The web or desktop settings screen of scheduled tasks.
• Other failure causes. This proof covers one: a disabled provider.
• list_scheduled_tasks. It has no lastRunError on either side, and this PR does not change it.

claude-sonnet-5 on T3 Code wrote the code. gpt-6.1-sol on T3 Code verified it.

[macroscopeapp]

Approvability

Verdict: Approved at 7d73b41

Macroscope's review found this PR approvable — The tool now returns the task's recorded failure reason alongside its run status. This additive diagnostic field leaves existing access controls and scheduling behavior unchanged.

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

[coderabbitai]

No actionable comments were generated in the recent review.

Walkthrough

The run_scheduled_task_now response now includes the scheduled task’s lastRunError. A test checks that a failed run returns its status and error text without making the MCP tool response an error.

Changes: Scheduled-task run response

Layer / File(s)	Summary
Expose last run error in tool result apps/server/src/mcp/toolkits/thread/tools.ts, apps/server/src/mcp/toolkits/thread/handlers.ts, apps/server/src/mcp/toolkits/core.test.ts	The result schema and handler include lastRunError. The test checks a failed run response with threadId: null, lastRunStatus: "failed", and the failure text.

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

Change: Bug fix

Suggested reviewers: juliusmarminge, t3dotgg

Merge Risk: Minimal · up to 3eb1c

The scheduled-task run tool now reports why a started run failed to dispatch. The change is small and additive, and no merge-blocking risk was identified.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title names the main change: run_scheduled_task_now now returns the reason a started run failed, which matches the added lastRunError field on the success path. It follows conventional commit styl…
Description check		The description follows the repository template closely. It has a Problem section with the expected behavior and reproduction context, a Change section that explains the two source edits, a Scope sect…
Linked Issues check		The only directly linked issue is #25647. It is closed, so it supplies historical context only. No active directly linked target remains, so no linked-issue coding requirements apply. The whole-PR dif…
Out of Scope Changes check		The whole-PR diff against the merge base changes three files. apps/server/src/mcp/toolkits/thread/tools.ts adds lastRunError: ScheduledTask.fields.lastRunError to the ScheduledTaskRunTool success sche…

Full details: Title check

Explanation

The title names the main change: run_scheduled_task_now now returns the reason a started run failed, which matches the added lastRunError field on the success path. It follows conventional commit style and is specific enough for a teammate scanning history.

Full details: Description check

Explanation

The description follows the repository template closely. It has a Problem section with the expected behavior and reproduction context, a Change section that explains the two source edits, a Scope section that justifies the absence of a linked issue as a small obvious fix and cites a sibling precedent, and a detailed Verification section with a focused test, a mutation check, command results, overlap analysis, and live-server evidence. It also names the model and harness that did the work, as the template requests. The only gap is that the screenshots are hosted externally and the evidence is command output rather than UI screenshots, which the template does not require here because there is no UI change. The Scope section also argues against the template's 'bug fixes only, link the issue' guidance rather than linking an issue, which a reviewer may question, but the author does explain the reasoning.

Full details: Linked Issues check

Explanation

The only directly linked issue is #25647. It is closed, so it supplies historical context only. No active directly linked target remains, so no linked-issue coding requirements apply. The whole-PR diff against the merge base shows the PR addresses the success path of run_scheduled_task_now, where a started run fails to dispatch. That is a separate gap from the refusal path in #25647. The incremental diff from the previous reviewed head could not be read, so this verdict relies on the whole-PR diff.

Full details: Out of Scope Changes check

Explanation

The whole-PR diff against the merge base changes three files. apps/server/src/mcp/toolkits/thread/tools.ts adds lastRunError: ScheduledTask.fields.lastRunError to the ScheduledTaskRunTool success schema. apps/server/src/mcp/toolkits/thread/handlers.ts adds lastRunError: task.lastRunError to the reply. apps/server/src/mcp/toolkits/core.test.ts adds a test that checks the reply forwards lastRunError through a mocked ScheduledTaskService. All three changes stay on the run_scheduled_task_now reply path. The diff shows no contract, settings, or access policy change. The incremental change since the previous reviewed head could not be read, so it is not separately confirmed.

Finishing Touches

Generate unit tests (beta)

• Create a new PR

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

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: 834eb51
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: 81a75b7e-ef30-45cd-8a38-005b1d840e96

Commits

Reviewing files that changed from the base of the PR and between 7d73b41 and 3eb1c85.

Files selected for processing: 1

• apps/server/src/mcp/toolkits/core.test.ts

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

[juliusmarminge]

Evidence

Create Demo and a paused Claude Haiku 5.5 task scheduled every 15 minutes, with a new thread each run in the project checkout. With Claude disabled, call list_scheduled_tasks and run_scheduled_task_now once through the real MCP endpoint. Capture Settings and display the actual MCP structuredContent in a replay thread. The full-access MCP client replaces the reporter's paid Codex caller; Claude is disabled in startup settings rather than toggled manually.

Proven: scenarios:prove exited 0. Base omits lastRunError; head returns the recorded reason alongside lastRunStatus: failed and threadId: null.

Environment on both sides: Chromium, 1280×800, light theme, fresh synthetic data, real server.

	Before	After
Commit	834eb51301	3eb1c859ed
MCP response
Recorded reason in Settings
Recording	Before recording	After recording

Scenario source