claude-code - 💡(How to fix) Fix [BUG] Cowork sub-agent permission resolver translates Linux mount paths to non-existent Windows paths

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

When a Cowork sub-agent (spawned via the Task tool) tries to read a file under the skills fuse mount, the desktop app's permission resolver translates the Linux mount path /sessions/<session-id>/mnt/.claude/skills/<skill>/... into the Windows path C:\Users<user>.claude\skills<skill>... and pops a blocking dialog asking the user to approve access to that path. Two things are wrong with this:

The Windows path in the dialog doesn't exist on disk. The real Windows source of the fuse mount is C:\Users<user>\AppData\Roaming\Claude\local-agent-mode-sessions\skills-plugin<plugin-id><account-id>\skills<skill> — not C:\Users<user>.claude\skills<skill>. The latter is the Claude Code (CLI) convention, not Cowork's actual on-disk layout. The resolver appears to be doing a naive string-level reverse translation (/sessions/<id>/mnt/<X> → C:\Users<user><X>) rather than consulting the live fuse mount table. The parent agent and sub-agent have asymmetric permissions in the same session. The orchestrating parent reads files from the skills mount freely with no dialog. When it spawns a Task sub-agent in the same session VM, under the same user, to read a different file in the same skill folder, the sub-agent is gated by a permission prompt. The dialog is blocking, so any scheduled Cowork task that spawns a sub-agent reading from the skills mount cannot complete unattended.

The combined effect: scheduled tasks that involve sub-agents reading skill files break by design, and when the dialog does fire, it asks the user to approve a phantom path — leaving them to either approve blindly (security risk) or deny (functionality loss) with no informed basis for the decision.

What Should Happen?

Either of the following would resolve the bug:

Sub-agents inherit the parent agent's read access to the skills mount within the same session. The parent and sub-agent run in the same session VM, under the same user, against the same read-only fuse mount. If the parent is authorized (implicitly or explicitly) to read a skill folder, a Task sub-agent it spawns should inherit that access without a fresh prompt. No dialog appears. If a permission dialog must be shown, it references the real Windows source path of the fuse mount — e.g. C:\Users<user>\AppData\Roaming\Claude\local-agent-mode-sessions\skills-plugin<plugin-id><account-id>\skills<skill> — resolved by consulting the live mount table, not by string-translating the Linux path into a Claude Code-style path that doesn't exist on disk.

In either case, scheduled tasks running unattended must not be blocked by interactive prompts. A scheduled task whose execution path crosses skill boundaries via a Task sub-agent should run end-to-end without user intervention.

Error Messages/Logs

Here's section 3. Say "next" when you're ready for section 4.

---

**3) Error Messages/Logs**

There is no error message per se — the failure mode is a blocking permission dialog rather than a thrown error. The relevant diagnostic evidence:

**Permission dialog text (the path the user is asked to approve):**

C:\Users\DiegoMontefusco\.claude\skills\minutes-maker

This Windows path does not exist on disk. Manually verified: `C:\Users\DiegoMontefusco\.claude\skills\` does not contain a `minutes-maker` folder, and the entire `.claude\skills\` tree at that location is not where Cowork's skills-plugin stores skills.

**Mount table entry (from `/proc/self/mounts` inside the session VM):**

/mnt/.virtiofs-root/shared/c/Users/DiegoMontefusco/AppData/Roaming/Claude/local-agent-mode-sessions/skills-plugin/9175aa88-42b3-4112-9fe6-1efb08d4275a/fa887296-da0d-4fb6-a8f5-5b4390c710b0/skills
on /sessions/dazzling-friendly-hamilton/mnt/.claude/skills
type fuse (ro,nosuid,nodev,relatime,...)


So the Linux path `/sessions/dazzling-friendly-hamilton/mnt/.claude/skills/minutes-maker/` is a fuse mount whose real Windows source is:

C:\Users\DiegoMontefusco\AppData\Roaming\Claude\local-agent-mode-sessions\skills-plugin\9175aa88-42b3-4112-9fe6-1efb08d4275a\fa887296-da0d-4fb6-a8f5-5b4390c710b0\skills\minutes-maker


**File the sub-agent was instructed to read (verified present and readable from the parent agent):**

/sessions/dazzling-friendly-hamilton/mnt/.claude/skills/minutes-maker/instructions/minutes-generation-instructions-default.md

`SKILL.md` in the same folder: 28,269 bytes, mode `r-x------`, read-only fuse mount.

**Suspected resolver logic:** the permission resolver appears to perform a string-level reverse translation `/sessions/<session>/mnt/<X>` → `C:\Users\<user>\<X>`, with `<X>` = `.claude/skills/minutes-maker`, producing the phantom path `C:\Users\DiegoMontefusco\.claude\skills\minutes-maker`. The resolver is not consulting the live fuse mount table to determine the real Windows source.

**Environment:**
- Product: Cowork mode (Claude Desktop)
- Host OS: Windows
- Date observed: 2026-05-08
- Session: `dazzling-friendly-hamilton`
- User: `DiegoMontefusco`
- Skills involved: `meeting-minutes-orchestrator` (parent) and `minutes-maker` (child spawning the Task sub-agent)
- Triggering execution mode: scheduled task running unattended

Steps to Reproduce

Here's section 4.

4) Steps to Reproduce

1. In Cowork on Windows, install (or have available) two skills where one orchestrates the other via a Task sub-agent. For this report we used meeting-minutes-orchestrator (parent) and minutes-maker (child). Any pair where the parent skill spawns a Task sub-agent that needs to read a file inside another skill's folder will reproduce the bug.

2. Confirm the skills are mounted at /sessions/<session-id>/mnt/.claude/skills/<skill>/ inside the session VM, with the real Windows source under C:\Users\<user>\AppData\Roaming\Claude\local-agent-mode-sessions\skills-plugin\<plugin-id>\<account-id>\skills\<skill>. You can verify this by running cat /proc/self/mounts | grep skills from the session shell.

3. Configure a scheduled Cowork task whose execution path triggers the orchestrator skill. The orchestrator should reach a point where it spawns a Task sub-agent and passes it a prompt instructing the sub-agent to read a file inside the skills mount — for example:

   Read the file at /sessions/<session-id>/mnt/.claude/skills/minutes-maker/instructions/minutes-generation-instructions-default.md and follow its instructions.

4. Have the parent agent itself read a different file in the same skill folder earlier in the run (e.g. SKILL.md). Confirm no permission dialog appears for the parent's read.

5. Run the scheduled task (or trigger the orchestrator manually — the bug reproduces in both modes; it just becomes blocking-and-unrecoverable in unattended scheduled runs).

6. Observe: when the Task sub-agent attempts its read, a blocking permission dialog appears on the Windows desktop asking the user to approve access to C:\Users\<user>\.claude\skills\<skill> (e.g. C:\Users\DiegoMontefusco\.claude\skills\minutes-maker).

7. Verify the dialog's path is phantom: open File Explorer or cmd and check C:\Users\<user>\.claude\skills\. The <skill> folder named in the dialog will not exist there. The real on-disk location is under AppData\Roaming\Claude\local-agent-mode-sessions\skills-plugin\....

8. Verify the blocking behavior: until the dialog is dismissed, the Task call does not return. In an unattended scheduled run with no human present, the task hangs indefinitely (or fails on a timeout, depending on the scheduler's behavior).

Minimal reproduction note: if you don't want to install the meeting-minutes skills, the bug should reproduce with any two-skill orchestrator/child pair where the parent invokes Task and the sub-agent's prompt instructs it to Read a path of the form /sessions/<id>/mnt/.claude/skills/<anything>/<file>. The specific skill content is irrelevant — the bug is in the permission resolver's path translation for Task sub-agents, not in the skills themselves.

Workaround currently in use (not a fix): have the orchestrating parent read the skill file's contents itself and embed them inline into the Task prompt, so the sub-agent never reads from the skills mount directly. This sidesteps the buggy resolver path but forces every orchestrator skill author to design around the bug.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

doesn't apply. the bug is in cowork desktop

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

Here's the Additional Information section.

Additional Information

Impact

Scheduled tasks that involve sub-agents reading from the skills mount cannot run unattended. Every run blocks at the permission dialog, which breaks the entire scheduled-task value proposition for any orchestrator skill that uses Task delegation across skill boundaries.

The asymmetric parent/child permissions are also surprising. The parent agent reads the skill folder freely; the sub-agent in the same VM, under the same user, reading the same files, is gated. Users have no easy way to predict or pre-approve this.

The dialog is misleading. It asks the user to approve access to a Windows path that does not exist on disk. This undermines trust in the permission system: users either approve blindly (security risk) or deny (functionality loss), with no real way to make an informed decision because the path shown is a phantom.

Suggested Fix

Two changes, ideally both:

1. Resolve permission paths through the live mount table. When checking permissions for a path under /sessions/<id>/mnt/..., the resolver should consult /proc/self/mounts (or its desktop-side equivalent) to find the real Windows source path of the fuse mount, and either suppress the dialog (if the parent already has access) or display the real path in the dialog.

2. Inherit parent-agent permissions for Task sub-agents within the same session. Sub-agents spawned by an authorized parent should automatically inherit the parent's read access to read-only paths the parent already has access to — at minimum the skills mount, plugins mount, and any project mount. Forcing re-authorization per sub-agent breaks unattended workflows by design.

Workaround Currently in Use (Not a Fix)

Skills that need to run unattended can sidestep the bug by having the orchestrating parent agent read the contents of any required skill files (instructions, templates, etc.) itself and embed them inline into the Task prompt. The sub-agent then never reads from the skills folder, and the buggy resolver path is avoided. This is what we are doing now to keep the meeting-minutes scheduled task functional, but it is not a real fix — it forces every orchestrator skill author to design around a bug that should not exist.

Other Notes

• The path C:\Users\<user>\.claude\skills\ is the convention used by Claude Code (the CLI tool), not Cowork. The resolver heuristic appears to have been ported from there without being adapted to Cowork's actual on-disk storage layout.
• The same issue almost certainly affects the plugins mount (/sessions/<id>/mnt/.remote-plugins/...) and may also affect the project mount, depending on how broadly the string-translation is applied. Worth checking.
• The orchestrator's own reads of the skills mount do not trigger the dialog — only the Task sub-agent's reads do. So the bug is specifically in the sub-agent permission code path, not the parent's. This is a useful narrowing for whoever fixes it.