Desktop WSL sessions get no scheduled-tasks host MCP: routines cannot be listed or created from inside a WSL session, and routines cannot target a WSL environment

Environment

• Claude Desktop for Windows 1.24012.9.0 (MSIX / Store install)
• Windows 11 Pro build 26200
• Session environment: WSL -> Ubuntu-22.04 (WSL 2.7.11.0, kernel 6.18.33.2)
• In-WSL agent binary: ~/.claude/remote/ccd-cli/2.1.219 (installed CLI 2.1.220)

Summary

When a Desktop session runs in a WSL environment, the agent has no Routines
surface at all. It cannot list, create, update, or run scheduled tasks, even
though the Routines section is visible in the app sidebar and routines exist for
the account. The only scheduling tool exposed is CronCreate, which is
explicitly session-only.

The same account, on the same machine, in a Local session, gets the full
mcp__scheduled-tasks__* toolset. The difference is the session environment.

Evidence

Collected from inside a WSL session, side by side with a Local session on the
same machine and account.

1. A WSL environment is served over the remote-session path, the same machinery

used for SSH remotes:

``
/home/<user>/.claude/remote/srv/<hash>/server --serve --socket .../rpc.sock
/home/<user>/.claude/remote/ccd-cli/2.1.219 ...
env: CLAUDE_SSH_DAEMON_CHILD=1, WSL_DISTRO_NAME=Ubuntu-22.04
``

1. The CLI carries a list of first-party host MCP servers:

``
["cowork","workspace","session-info","mcp-registry","plugins",
"scheduled-tasks","dispatch","ide"]
``

None of them is attached in the WSL session, including scheduled-tasks.

1. Local session, same machine and account: mcp__scheduled-tasks__create_scheduled_task

is present, along with the list / update / delete tools. WSL session: none of
them resolve.

1. The only scheduler tool available in the WSL session is CronCreate, whose

own schema states that durable "has no effect" and that jobs are in-memory
and die with the session. So there is no path to persist a routine from a WSL
session.

1. Local routines are stored in the Windows profile at

C:\Users\<user>\.claude\scheduled-tasks\<taskId>\SKILL.md. Inside WSL,
$HOME is /home/<user> and there is no ~/.claude/scheduled-tasks, so the
store is not reachable through the session's own home either.

1. Cloud routines are unaffected: RemoteTrigger {action:"list"} returns HTTP 200

from the same WSL session. The gap is specific to the local / host-side
routines surface.

Expected

A Desktop session running in a WSL environment should attach the same
scheduled-tasks host MCP a Local session gets, so the agent can list, create,
update, and run routines.

Steps to reproduce

1. On Windows Desktop with a WSL distro installed, start a new session and pick

the WSL distro in the environment picker.

1. Ask Claude to list your routines, or to create one.
2. The agent has no routine tooling. Only CronCreate (session-only) is

available, so nothing can be persisted.

1. Open a Local session on the same machine and account and ask the same thing.

mcp__scheduled-tasks__create_scheduled_task and its siblings are available
there.

Related gap: routines have no environment binding

Even when a routine is created from a Local session, there is no way to declare
that it should execute inside a WSL distro. The full parameter set of
mcp__scheduled-tasks__create_scheduled_task is:

taskId, prompt, description, cronExpression, fireAt, notifyOnCompletion

No cwd, no environment, no distro. The scheduled run therefore happens on
the Windows host, and every routine prompt that needs the Linux toolchain has to
hand-wrap each command:

wsl -d <distro> -- bash -lc "<cmd>"

That workaround is brittle. In our experience, command bodies containing loops,
variable assignments, or backticks silently come back empty through that wrapper,
so prompts end up writing temporary .sh files as a second workaround.

Ask: let a routine declare its execution environment (WSL distro + working
directory), the same way a session does through the environment picker.

Impact

For teams whose toolchain is Linux-only and who therefore run Desktop in WSL mode
full time, routines are effectively unusable from the session where the work
happens. They can only be authored from a Local session, and they only ever run
against the Windows host.