[BUG] Desktop local scheduled task: built-in AskUserQuestion is absent from the session tool surface, and the known workaround does not restore it

[BUG] Desktop local scheduled task: built-in AskUserQuestion is absent from the session's tool surface, and the known "send a user message" workaround does not restore it

Environment

• Claude Desktop app 2.110.0, CLI 2.1.271, Windows 11 (MSIX install)
• Local Desktop scheduled task (Routines → Local), not a cloud routine
• Permission mode: auto; model claude-opus-5
• Working folder is a trusted local folder; useWorktree: false

Summary

In a session started by a local Desktop scheduled task, the built-in AskUserQuestion tool is not present in the tool surface. ToolSearch select:AskUserQuestion returns No matching deferred tools found, and the tool cannot be called.

This differs from the already-reported connector problems (#43397, #36327, #94305) in two ways that I think make it worth a separate report:

1. It affects a built-in tool, not an MCP connector.
2. The workaround documented in #43397 — "Sending a user message into the same session immediately makes all connectors available" — does not work here. I sent six user messages over 12 minutes; the tool never appeared.

Meanwhile, other scheduled-task sessions of the same app instance do end up with the tool. I could not determine what distinguishes them.

Reproduction

I built a throwaway routine that does nothing but probe, so the result is not confounded by real work.

1. Create a local scheduled task with schedule Manual, whose prompt is only:

• call ToolSearch with select:AskUserQuestion
• print PROBE N AskUserQuestion: present|absent plus the local time
• repeat the probe as the first action of every turn that starts with a user message

1. Click Run now.
2. Observe probe 1.
3. Send several plain user messages into the session; observe each probe.
4. Send a slash command (/explain-usage); observe.
5. Ask it to write a file (triggers the Write tool); observe.

Result — 7 probes over 12 minutes, all absent:

| Probe | User messages so far | Completed turns | Result |
|---|---|---|---|
| 1 | 0 | 1 | absent |
| 2 | 1 | 2 | absent |
| 3 | 2 | 3 | absent |
| 4 | 3 | 4 | absent |
| 5 | 4 | 5 | absent |
| 6 | 5 | 5 | absent |
| 7 | 6 | 5 | absent |

Probe 7 came after the run's status had already become succeeded, and after a file write that completed without any permission prompt (permission mode auto).

Independent confirmation from outside the session

Each run's record in %APPDATA%\Claude\claude-code-sessions\<acct>\<org>\local_<id>.json carries toolSurfaceSnapshot.familyHashes.builtin. Two distinct values show up across sessions of the same app instance:

• 9563e075b5f09559 — sessions where AskUserQuestion is absent
• c0f040a298ff6adf — sessions where it is present

The hash matched the in-session probe on all 7 data points, so the snapshot is a reliable external read of the tool surface. The probe session stayed on 9563e075b5f09559 throughout.

What I ruled out

None of these changed the tool surface:

• the user entering the session and typing (6 messages)
• number of completed turns (5 here; another session had it at 3 turns, a third did not have it at 3 turns)
• invoking a slash command / skill
• a tool call that writes to disk
• the run reaching status succeeded
• app restart — toolSurfaceSnapshot.appRunId was identical across all compared sessions
• lastFocusedAt, sessionPermissionUpdates, alwaysAllowedReasons, chromePermissionMode, remoteControlAutoEligible — identical between sessions that had the tool and sessions that did not
• scheduledRunContinued — true in both groups

Two sessions of the same routine with the same turn count landed in different groups, so I could not find any field in the session record that predicts which surface a session gets.

Related observations (possibly the intended design, but undocumented)

In a scheduled-task session that does have the tool, every call is refused auto-approval and raises a permission request:

[CCDScheduledTasks] Not auto-approving "AskUserQuestion" in scheduled task "<task-id>": no suggestions on request
Emitted tool permission request <id> for AskUserQuestion in session local_<id>
Received permission response for <id>: once (tool: AskUserQuestion)

This is consistent with the documented behaviour for requiresUserInteraction tools — "prompt on every call and don't offer an always-allow option. Runs that call these tools stall each time." In the Code tab the approval card and the question card are fused, so the user does not perceive an extra click. That part seems fine.

Also, run_scheduled_task is refused in such a session with "This tool is unavailable in unattended sessions (scheduled-task runs and remote-dispatched trees)" — i.e. the session is still classified as unattended even when its tool surface is the full one. So "has the manual tool surface" and "is treated as attended" are two independent states.

Expected

Either of:

• (a) AskUserQuestion is available in a scheduled-task session, and stalls the run until the user answers — consistent with the documented requiresUserInteraction behaviour; or
• (b) it is intentionally withheld from unattended runs, and that is documented on the Desktop scheduled tasks page, and surfaced to the model (e.g. the tool appears but returns a clear "not available in unattended sessions" error, the way run_scheduled_task already does).

The same request for documenting intentional withholding was made in #94305.

Actual

The tool is silently absent, with no signal distinguishing "withheld by design" from "failed to load". An agent in that session cannot tell which, and — unlike the connector case in #43397 — cannot recover it by asking the user to send a message.

Why it matters

We run a two-slot pipeline of local scheduled tasks that implement a development workflow. The agent must ask the owner to approve a plan or resolve an ambiguity. Because AskUserQuestion may or may not exist depending on something we cannot observe, every prompt has to defensively probe with ToolSearch before offering a button, and fall back to ExitPlanMode. Documented behaviour in either direction would remove the guesswork.

Related

• #43397 — cloud routines, MCP connectors, No matching deferred tools found; workaround "send a user message" (does not work for this case)
• #36327 — desktop scheduled task, MCP/tool access
• #94305 — asks that intentional withholding of tools in scheduled sessions be documented