[BUG] ListAgents / SendMessage missing from tool registry in Desktop scheduled-task and Remote Control sessions (bisected to Desktop 1.44121.4 -> 1.46388.1)

Status Open

Reported on v2.1.260

Maintainer reply None cached

Activity 3 comments · opened Sep 5, 2026

Summary

Since Claude Desktop auto-updated from 1.44121.4 to 1.46388.1, the built-in cross-session messaging tools ListAgents and SendMessage are no longer registered in Code sessions that Desktop starts as scheduled tasks, or that are driven through Remote Control.

They are absent from the tool registry and from the deferred-tool list — ToolSearch returns No matching deferred tools found — so this is not a permission-rule problem.

Sessions started interactively on the desktop, and sessions started from the standalone CLI, still have both tools. Same machine, same account, same settings, same hour.

Evidence

All four were run on the same machine, same account, same settings, within a few hours of each other:

| How the session was started | ListAgents |
|---|---|
| Desktop, interactive local Code tab | present (listed 7 agents) |
| Desktop, scheduled task (routine) | absent |
| Desktop, Remote Control (driven from phone) | absent |
| standalone CLI ~\.local\bin\claude.exe (v2.1.250) | present (listed 3 agents) |

The two "absent" cases were asked explicitly to check their own tool list. Both answered that neither ListAgents nor SendMessage exists, and that ToolSearch returns No matching deferred tools found.

Bisect boundary

From %LOCALAPPDATA%\AnthropicClaude\Squirrel-Update.log:

[04/09/26 13:25:29] info: ApplyReleasesImpl: Writing files to app directory:
    C:\Users\<user>\AppData\Local\AnthropicClaude\app-1.46388.1
[04/09/26 13:25:48] info: ApplyReleasesImpl: cleanDeadVersions:
    exclude current version folder app-1.44121.4

Timeline (JST):

2026-09-04 04:30 — a scheduled-task session ran ListAgents, then sent two SendMessage calls. Both succeeded. Recorded in the session log. Desktop was 1.44121.4.
2026-09-04 13:25:29 — Desktop auto-updated 1.44121.4 -> 1.46388.1.
2026-09-04 15:57 onward — same routines, same settings, no configuration changes: both tools gone.
Still gone on 1.46388.2 (09-04 23:18) and 1.46388.3 (09-05 05:50).

Note on the bundled runtime: Desktop's bundled Claude Code was still 2.1.255 at 15:57; 2.1.260 was only written at 16:18. The regression therefore precedes the runtime bump, and the variable that actually changed across the boundary is the Desktop host version.

Ruled out

No permissions.deny entry for SendMessage or ListAgents (checked both user and project settings).
Version requirements are met: native Windows needs v2.1.234+, same-machine messaging needs v2.1.248+. The standalone CLI here is 2.1.250 and Desktop's bundled runtime is 2.1.260.
Not crossSessionInbound — that governs inbound delivery, not tool registration, and the working and broken sessions share the same settings.
Not a ToolSearch usage problem — the tools are absent from the deferred list as well.
No configuration on this machine was changed between the working run (04:30) and the broken runs (15:57 onward).

Related, but distinct

The Desktop MCP surface (mcp__ccd_session_mgmt__send_message, list_events) refuses with:

This tool is unavailable in unattended sessions (scheduled-task runs and remote-dispatched trees).
This tool is unavailable in sessions dispatched by a remote orchestrator.

That reads like an intentional safety limit on the Desktop MCP surface, and is not what this report is about. This report is about the built-in ListAgents / SendMessage disappearing from the tool registry entirely in those same session kinds. The cross-session messaging documentation does not describe tool registration as conditional on how the session was started.

Environment

Windows 11 (10.0.26200)
Claude Desktop 1.46388.3, bundled Claude Code runtime 2.1.260
standalone Claude Code 2.1.250

Expected

Sessions started by Desktop as scheduled tasks, or driven through Remote Control, should keep ListAgents / SendMessage, as they did on 1.44121.4.

If the gating is intentional, please document it and ideally make it configurable. Automated routines that need to report a finding to a human-driven session currently have no direct channel at all: they cannot use the built-in tools (absent), and the Desktop MCP surface refuses them by design.

View original on GitHub ↗

3 Comments

0u0v · 3 hours ago

Update 2026-09-05. One correction and two additions after further testing on the same machine and account. Latest installed: Desktop 1.46388.3, bundled Claude Code 2.1.260 (2.1.255 also present), standalone CLI 2.1.250, Windows 11 10.0.26200.

1. Correction: an interactive Desktop session has `ListAgents` but not `SendMessage`

The Summary above says interactive Desktop sessions and the standalone CLI "still have both tools", but the evidence table only recorded ListAgents; SendMessage had not been separately verified for those rows. Rechecked today with 1.46388.3 installed:

Desktop, interactive Code-tab session. Launched on the PC from a task chip in the Desktop Code tab (not the plain new-session button), steered from the PC keyboard. It has a Remote Control bridge (it appears in the Claude mobile app's session list), which seems to be the default for Desktop Code-tab sessions on this account; a Code-tab session opened with the plain new-session button was not separately tested.

ListAgents: in the tool list and works. It listed 11 peers (7 local interactive sessions, 4 Remote Control sessions).
SendMessage: not in the tool list. ToolSearch with select:SendMessage returns No matching deferred tools found.
Inbound delivery works: two messages sent with SendMessage from a standalone CLI session on the same machine arrived in this session (10:39 and 10:44 JST).

Standalone CLI ~\.local\bin\claude.exe (v2.1.250), run as claude -p from the same project directory, same account:

ListAgents: present.
SendMessage: present as a deferred tool. ToolSearch with select:SendMessage returns [{"type":"tool_reference","tool_name":"SendMessage"}] (from that session's transcript, not the model's summary). An interactive CLI session on the same machine also sent messages successfully today (the two deliveries above).

Corrected table. The interactive and CLI rows were rechecked today; the two absent/absent rows are carried over from the original report (observed on 1.46388.1 through 1.46388.3, see Bisect) and were not re-run today.

| How the session was started | ListAgents | SendMessage |
|---|---|---|
| Desktop, Code tab (chip-launched, Remote Control bridge present, driven from PC) | present | absent |
| Desktop, scheduled task (routine) | absent | absent |
| Desktop, Remote Control (driven from phone) | absent | absent |
| standalone CLI ~\.local\bin\claude.exe (v2.1.250) | present | present (deferred) |

So the Summary's statement that interactive Desktop sessions "still have both tools" is wrong for SendMessage on 1.46388.3; none of the three Desktop-started session kinds tested here has it, while the standalone CLI on the same machine does. SSH and WSL Code-tab sessions were not tested. Whether SendMessage was present in interactive Desktop sessions before the update, I cannot say: I have no pre-update record of it there. The only pre-update record remains the 04:30 JST 2026-09-04 scheduled-task run in the Bisect section, which sent SendMessage successfully on 1.44121.4.

Session transcripts (JSONL) for the Desktop session and the CLI check are available on request.

2. Possibly separate: scheduled-task runs are no longer listed in the Claude mobile app

Until recently, scheduled-task runs on this machine showed up in the Claude mobile app's session list (Code tab) after they ran. I have no log of that state and cannot pin the change to the update date from records. Now they still execute (lastRunAt advances, results land on disk), but they are not listed. Concretely, at 10:28 JST today the mobile app's Code tab for this account listed exactly one session, the Desktop session described above; the scheduled-task runs that executed on the same machine at 08:10 and 09:46 JST (by lastRunAt) were not listed.

The mobile list appears to show only sessions with a Remote Control bridge (the other local sessions that ListAgents saw were not listed either), so this may be "scheduled-task runs no longer get a Remote Control bridge" rather than a listing defect; our local notes for a scheduled run on 2026-09-04 16:44 JST record it as having no remote bridge. This may be unrelated to the tool removal; I can file it separately if that is more useful.

3. On the docs

The Desktop docs, under "Work across sessions", say: "Through this surface, Claude can't send cross-session messages from a session nobody is watching, such as a scheduled-task run, and can't deliver messages into one." That sentence is about the Desktop app's own session-management surface, the same one whose refusal text is quoted under "Related, but distinct" above, and the same page separates it from the built-in feature: "Cross-session messaging separately lets Claude message your other Claude Code sessions, including terminal sessions." The cross-session messaging page names only a version shortfall or a deny rule as things that remove the tools; both are ruled out above.

If the built-in tools are gated on the same "unattended" criterion as the Desktop surface, that would not by itself explain the result in section 1: a person was at the keyboard, though a Remote Control bridge was present.

Possibly related open Windows Desktop issues: #91211 (background sessions stop processing cross-session messages) and #89658 (peer discovery does not scan \\.\pipe\LOCAL\). Both are about delivery and discovery between sessions that have the tools; this issue is about the tools not being registered at all, so I have kept it separate.

0u0v · 3 hours ago

Follow-up to section 1 above: the untested case is now tested.

A Desktop Code-tab session opened with the plain new-session button (not from a task chip), driven from the PC keyboard, same machine and account, 1.46388.3: ToolSearch with select:SendMessage returns No matching deferred tools found. SendMessage is not in that session's tool list and cannot be loaded.

So the chip-launched row in the corrected table is not special; a plain interactive Desktop Code-tab session gives the same result.

0u0v · 2 hours ago

Two more data points from today, same machine and account.

Standalone CLI, both sides. The standalone CLI has since auto-updated to 2.1.261. Two interactive CLI sessions started from PowerShell (~\.local\bin\claude.exe) exchanged SendMessage in both directions, five round trips, without issue. So same-machine discovery and the named-pipe path work on this machine; the problem is specifically that Desktop-started sessions (bundled runtime 2.1.260) don't get SendMessage registered. This also separates it from #89658, where the pipe itself is not found.

Cost of the workaround. Starting sessions from the standalone CLI restores messaging, but those sessions don't have the Desktop app's built-in browser tools (preview_start is not registered; list_connected_browsers returns []), so work that depends on the Desktop browser can't move to the CLI. On this build a session can have cross-session messaging or the Desktop toolset, not both.

Not closing this; nothing is fixed on our side.