## Summary Dispatch's `start_code_task` tool appears to have no WSL 2 code path. Every path format that could identify a WSL-resident workspace fails, each in a different way: - the canonical `wsl: : ` key → `cwd must be an absolute path` - an absolute Linux path → silently mistranslated to `C:\home\...` → `no longer exists` - a UNC path (`\\wsl.localhost\...`) → rejected outright This is inconsistent with Claude Code Desktop's **Code tab**, which ships documented, first-class WSL

Cowork Dispatch: `start_code_task` cannot target WSL2 workspaces — rejects `wsl:` keys, mistranslates absolute Linux paths to `C:\`

Status Open

Reported on v2.1.220

Maintainer reply None cached

Workaround ✓ Mentioned in description ↑

Activity 0 comments · opened Jul 25, 2026

Summary

Dispatch's start_code_task tool appears to have no WSL 2 code path. Every path format
that could identify a WSL-resident workspace fails, each in a different way:

the canonical wsl:<distro>:<path> key → cwd must be an absolute path
an absolute Linux path → silently mistranslated to C:\home\... → no longer exists
a UNC path (\\wsl.localhost\...) → rejected outright

This is inconsistent with Claude Code Desktop's Code tab, which ships documented,
first-class WSL 2 support (environment picker → WSL section → distro → folder picker
browsing inside the distribution).

Environment

| | |
|---|---|
| Windows | 11, Version 10.0.26200.8875 |
| WSL | WSL 2, Ubuntu-22.04 (Ubuntu 22.04.5 LTS) |
| Kernel | 6.6.87.2-microsoft-standard-WSL2 |
| Claude Code CLI (inside WSL) | 2.1.220 |
| Claude Desktop | 1.24012.9 (03c61d) |
| Repo location | /home/<user>/dev/<repo> — inside the distro's filesystem |

Reproduction

Ask Dispatch to start a coding task against a repo that lives in the WSL filesystem.
Three cwd formats attempted, three distinct failures:

| # | cwd passed to start_code_task | Result |
|---|---|---|
| 1 | \\wsl.localhost\Ubuntu-22.04\home\<user>\dev\<repo> | Rejected outright — UNC paths not accepted |
| 2 | wsl:ubuntu-22.04:/home/<user>/dev/<repo> | cwd must be an absolute path |
| 3 | /home/<user>/dev/<repo> | Mistranslated to C:\home\<user>\dev\<repo>, then failed as no longer exists |

Attempt 3 is the most diagnostic. A leading / is being resolved against the Windows
drive root, which means the validator is applying Windows path semantics with no awareness
that a WSL target is even possible. Attempt 2 shows the canonical WSL workspace identifier
is not recognized as a valid cwd shape at all.

The same workspace works in the Code tab

A WSL 2 session against this exact folder starts and runs correctly from the Code tab
(environment picker → WSL → Ubuntu-22.04 → project folder). The session footer confirms
the resolved target — distro Ubuntu-22.04, the project folder, with git branch and
worktree controls active.

So on one machine, in one application, against one folder: the Code tab resolves the WSL
workspace correctly, and Dispatch cannot address it at all. The defect is in Dispatch's
cwd handling — not in WSL, the distribution, trust state, or the workspace record.

The workspace is already registered and trusted

This is not a discovery, registration, or trust problem. The Windows-side
%USERPROFILE%\.claude.json projects map already contains the canonical WSL key,
written by Claude Desktop itself:

{
  "projects": {
    "C:/Users/<user>/dev/<repo>":                { "hasTrustDialogAccepted": true },
    "wsl:ubuntu-22.04:/home/<user>/dev/<repo>":  { "hasTrustDialogAccepted": true },
    "C:\\Users\\<user>\\dev\\<repo>":            { "hasTrustDialogAccepted": true }
  }
}

The identifier Dispatch would need is sitting in the config file. Dispatch simply has no
code path that consumes it.

_Minor secondary observation: the duplicate C:/… and C:\… keys pointing at the same
directory suggest path normalization is inconsistent in whatever writes this map._

Expected behavior

start_code_task should accept the same wsl:<distro>:<abs-linux-path> workspace
identifier Claude Desktop already persists to .claude.json, and launch the session
inside the distribution — the same way the Code tab's WSL environment picker does.

Impact

The Code tab documents WSL 2 support, but Dispatch cannot reach it. For developers whose
repositories live inside the WSL filesystem — the configuration Anthropic's own
documentation recommends — Dispatch is unusable from mobile.

From the WSL docs:

Use a WSL session when your repository lives inside the distribution's filesystem. Working on those files from Windows goes through a network filesystem, which is slow and breaks file watching; running the session inside the distribution avoids both.

The only available workaround is maintaining a second, Windows-side clone. That
reintroduces precisely the performance and file-watching problems the WSL documentation
warns about, and adds a permanent sync burden between two copies of the same repo.

Related issues

#38276 — requested Cowork/Dispatch/remote-session support on Linux and WSL2. Closed

as not planned / invalid with the note "Issue doesn't seem to be related to Claude
Code", and no substantive response. Given the Code tab ships documented WSL 2 support
and this failure is in a Claude Code tool's cwd validator, that triage looks incorrect.

#49933 — native WSL remote integration for Claude Code Desktop (open). Overlaps on

the underlying platform gap but does not cover Dispatch or start_code_task.

Suggested fix

Smallest viable change: teach the start_code_task cwd validator to recognize the
wsl:<distro>:<path> form and route it to the WSL session launcher the Code tab already
uses.

Failing that, accept absolute POSIX paths alongside an explicit distro parameter — rather
than silently resolving a leading / against C:\, which turns a valid Linux path into a
confusing "no longer exists" error.

View original on GitHub ↗