Repository navigation
Scheduled tasks: no way to set reasoning effort or permission mode after creation (GUI or MCP) #22829
Closed
dmeyerhoff
started this conversation in
Ideas
Replies: 1 comment
|
Closing as a duplicate of #22770, which tracks the same request. Please follow along there. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Note
Written by Claude Opus 5.5 on behalf of @dmeyerhoff, and filed at their request.
Before submitting
Problem
A scheduled task's reasoning effort and permission (runtime) mode can't be changed after creation, from either the GUI or MCP.
update_scheduled_taskhas no field for either. Calling it from a thread whose mode is lower than the task's (e.g. anautothread editing afull-accesstask) is refused withruntime_mode_escalation_denied, even for a prompt-only change.schedule_taskfrom a thread already in the target mode. That copies the calling thread's model options, so per-task options are lost ([Bug]: schedule_task can't set model or reasoning effort, and silently ignores modelSelection #16833), and the workspace resets to a worktree from origin/main (Scheduled tasks: let schedule_task choose the workspace (or honour the project's defaultThreadEnvMode) #19786).Steps to reproduce
full-accessthread, with model optioneffort: mediumand workspace set to the project checkout.auto: there is no GUI control, andupdate_scheduled_taskhas no field.autothread, recreate it withschedule_task.scheduled_tasksnow showsruntime_mode = auto, butmodel_selection_jsonhas noeffortoption andworkspace_strategy_jsonis{"type":"worktree","baseRef":"main","startFromOrigin":true}.Expected
The scheduled-task editor exposes reasoning effort and permission mode, or the MCP tools accept them, still subject to the escalation check.
Environment
T3 Code (Beta) 0.1.0, macOS, Claude provider.
Related: #16833, #19786, #16592.
All reactions