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?

[BUG] CRITICAL: P0 .skill file "Save and Replace" silently fails. Claude Cowork packages the skill from the host-mounted path (which had the OLD files), not from the VM working copy where the edits actually lived causes cascading scheduled task failures Severity: P0 / Critical — Silent data loss affecting all skill edits.

BAD BAD BAD

Severity: P0 / Critical — Silent data loss affecting all skill edits

Environment

• OS: macOS (Apple Silicon)
• App: Claude Desktop (Cowork mode), Claude Code 2.1.92
• Date: 2026-04-11
• User: Nicolas Cravino

Summary

The .skill file "Save and Replace" installer does not overwrite existing skill files. It silently succeeds (no error shown to user) but leaves the old skill files untouched on disk. This means every skill edit made through the .skill installer is silently dropped.

This has caused weeks of cascading failures across 10+ scheduled tasks that depend on updated skill definitions, with the user unable to determine why their skill edits were not taking effect.

Impact

The user has 11 scheduled tasks running daily/weekly newsletter pipelines (Efinew daily/weekly, SAP newsletter, Pascal newsletter daily/weekly, TAB newsletter, etc.). Over the past 2+ weeks, the user has made multiple rounds of skill edits to fix bugs and add features to these skills. Each time:

1. User edits the skill in a Cowork session
2. User packages the skill as a .skill file
3. User installs via "Save and Replace" — appears to succeed
4. Scheduled task runs with the old, broken skill definition
5. Task fails with errors
6. User re-edits, re-packages, re-installs — same silent failure

Observed failure history from just one task (Efinew daily):

• Apr 10 (yesterday): Error
• Apr 9: Error
• Apr 8: Error
• Apr 7: Skipped
• Apr 6: Error + Skipped
• Apr 5: Error
• Apr 4: Error
• Apr 3–1: Errors continue

This pattern repeats across all 10+ scheduled tasks. The user spent weeks debugging skill logic, unaware that the real problem was that edits were never being persisted.

Steps to Reproduce

1. Have an existing skill installed in Cowork (e.g., wiki-curator)
2. Edit the skill's SKILL.md in a Cowork session (add new sections, change content)
3. Package as skillname.skill (zip archive with skillname/SKILL.md inside)
4. Open the .skill file in Claude Desktop
5. Click "Save and Replace" when prompted
6. Observe: UI shows success. No error.
7. Open a new Cowork session and read the skill — old version is still there

Expected Behavior

"Save and Replace" should overwrite all files in the installed skill directory with the contents of the .skill package.

Actual Behavior

• The install dialog appears to succeed (no error message)
• Files on disk are unchanged — the old SKILL.md remains
• The Cowork VM mounts the old, unmodified skill files
• Scheduled tasks execute with the old skill definition
• User has no indication that the install failed

Evidence

Inside the .skill package (correct, updated content):

Archive:  wiki-curator.skill
  Length      Date    Time    Name
---------  ---------- -----   ----
    22471  2026-04-11 22:12   wiki-curator/SKILL.md        <-- 549 lines, has new sections
     2771  2026-04-11 22:12   wiki-curator/references/wiki-structure.md
    10879  2026-04-11 22:12   wiki-curator/scripts/detect_changes.py
    14086  2026-04-11 22:12   wiki-curator/scripts/generate_sitemap.py

Installed on disk after "Save and Replace" — unchanged:

grep -n "spidernic\|Autonomous\|pre-approved" ~/.claude/skills/wiki-curator/SKILL.md
# (no output — new content is missing)

Actual Cowork skills directory:

/Users/spider/Library/Application Support/Claude/local-agent-mode-sessions/skills-plugin/f7bc28d7-29ae-4afb-9416-fd568a5d42e1/b8c94e10-2109-48cc-b4a3-9fe7293ba06a/skills/

Note: this is NOT ~/.claude/skills/ — the installer may be writing to the wrong location, or not writing at all.

Root Cause Hypothesis

The installer may be:

1. Writing to ~/.claude/skills/ (CLI location) instead of the Cowork skills directory
2. Not overwriting due to a file permission or directory-exists check
3. Silently catching an error without surfacing it to the user

Workaround

Mount the actual Cowork skills directory via request_cowork_directory and write files directly:

/Users/spider/Library/Application Support/Claude/local-agent-mode-sessions/skills-plugin/f7bc28d7-29ae-4afb-9416-fd568a5d42e1/b8c94e10-2109-48cc-b4a3-9fe7293ba06a/skills/

This is fragile (UUID paths may change) and requires the user to know the internal directory structure.

Third Impact Vector: Corrupted .skill Deliverables to Customers

Because the installed skill files on the host are never updated, when a Cowork session packages a .skill file for distribution, it reads from the mounted host path (which contains the old, unedited files) rather than the VM's working copy where edits were actually made. This means:

1. User edits a skill in the VM (changes are correct in the VM's working directory)
2. User asks to package and export a .skill file
3. The packaging step reads from the host-mounted skill directory — which still has the old version
4. The exported .skill file contains stale, pre-edit content
5. User delivers this to customers believing it contains their edits
6. Customers receive broken/outdated skills

This is a supply chain integrity issue — the user has unknowingly distributed incorrect skill packages to paying customers over multiple weeks.

Why This is P0

1. Silent data loss — No error, no warning. User believes edits are saved.
2. Cascading impact — Every scheduled task that depends on the edited skill breaks.
3. Weeks of user time wasted — Debugging skill logic when the real problem is the installer.
4. No discoverability — Only discovered by accident when grep showed missing content.
5. Core workflow broken — Editing skills is a fundamental Cowork operation. If "Save and Replace" doesn't work, the entire skill iteration loop is broken.
6. Customer-facing impact — Exported .skill files contain stale content, meaning customers receive broken deliverables. This is a supply chain integrity failure.

Related Issues

• #26172 — Skills not loading to Claude Cowork on Mac
• #26254 — SKILL.md files not mounted in container
• #26998 — Skills not saving/loading on Windows

Additional Context

The third screenshot shows that today's run (Apr 11 at 3:09 AM) is STILL prompting for permission to run commands — despite the skill being edited to include an "Autonomous operation" section that pre-approves all access. This confirms the edit was never installed.

What Should Happen?

Claude Cowork MUST package the skill from rom the VM working copy where the edits actually lived, AND NOT FROM the host-mounted path (which had the OLD files) !!

Error Messages/Logs

Steps to Reproduce

[BUG] CRITICAL: .skill file "Save and Replace" silently fails — causes cascading scheduled task failures

Severity: P0 / Critical — Silent data loss affecting all skill edits

Environment

• OS: macOS (Apple Silicon)
• App: Claude Desktop (Cowork mode), Claude Code 2.1.92
• Date: 2026-04-11
• User: Nicolas Cravino

Summary

The .skill file "Save and Replace" installer does not overwrite existing skill files. It silently succeeds (no error shown to user) but leaves the old skill files untouched on disk. This means every skill edit made through the .skill installer is silently dropped.

This has caused weeks of cascading failures across 10+ scheduled tasks that depend on updated skill definitions, with the user unable to determine why their skill edits were not taking effect.

Impact

The user has 11 scheduled tasks running daily/weekly newsletter pipelines (Efinew daily/weekly, SAP newsletter, Pascal newsletter daily/weekly, TAB newsletter, etc.). Over the past 2+ weeks, the user has made multiple rounds of skill edits to fix bugs and add features to these skills. Each time:

1. User edits the skill in a Cowork session
2. User packages the skill as a .skill file
3. User installs via "Save and Replace" — appears to succeed
4. Scheduled task runs with the old, broken skill definition
5. Task fails with errors
6. User re-edits, re-packages, re-installs — same silent failure

Observed failure history from just one task (Efinew daily):

• Apr 10 (yesterday): Error
• Apr 9: Error
• Apr 8: Error
• Apr 7: Skipped
• Apr 6: Error + Skipped
• Apr 5: Error
• Apr 4: Error
• Apr 3–1: Errors continue

This pattern repeats across all 10+ scheduled tasks. The user spent weeks debugging skill logic, unaware that the real problem was that edits were never being persisted.

Steps to Reproduce

1. Have an existing skill installed in Cowork (e.g., wiki-curator)
2. Edit the skill's SKILL.md in a Cowork session (add new sections, change content)
3. Package as skillname.skill (zip archive with skillname/SKILL.md inside)
4. Open the .skill file in Claude Desktop
5. Click "Save and Replace" when prompted
6. Observe: UI shows success. No error.
7. Open a new Cowork session and read the skill — old version is still there

Expected Behavior

"Save and Replace" should overwrite all files in the installed skill directory with the contents of the .skill package.

Actual Behavior

• The install dialog appears to succeed (no error message)
• Files on disk are unchanged — the old SKILL.md remains
• The Cowork VM mounts the old, unmodified skill files
• Scheduled tasks execute with the old skill definition
• User has no indication that the install failed

Evidence

Inside the .skill package (correct, updated content):

Archive:  wiki-curator.skill
  Length      Date    Time    Name
---------  ---------- -----   ----
    22471  2026-04-11 22:12   wiki-curator/SKILL.md        <-- 549 lines, has new sections
     2771  2026-04-11 22:12   wiki-curator/references/wiki-structure.md
    10879  2026-04-11 22:12   wiki-curator/scripts/detect_changes.py
    14086  2026-04-11 22:12   wiki-curator/scripts/generate_sitemap.py

Installed on disk after "Save and Replace" — unchanged:

grep -n "spidernic\|Autonomous\|pre-approved" ~/.claude/skills/wiki-curator/SKILL.md
# (no output — new content is missing)

Actual Cowork skills directory:

/Users/spider/Library/Application Support/Claude/local-agent-mode-sessions/skills-plugin/f7bc28d7-29ae-4afb-9416-fd568a5d42e1/b8c94e10-2109-48cc-b4a3-9fe7293ba06a/skills/

Note: this is NOT ~/.claude/skills/ — the installer may be writing to the wrong location, or not writing at all.

Root Cause Hypothesis

The installer may be:

1. Writing to ~/.claude/skills/ (CLI location) instead of the Cowork skills directory
2. Not overwriting due to a file permission or directory-exists check
3. Silently catching an error without surfacing it to the user

Workaround

Mount the actual Cowork skills directory via request_cowork_directory and write files directly:

/Users/spider/Library/Application Support/Claude/local-agent-mode-sessions/skills-plugin/f7bc28d7-29ae-4afb-9416-fd568a5d42e1/b8c94e10-2109-48cc-b4a3-9fe7293ba06a/skills/

This is fragile (UUID paths may change) and requires the user to know the internal directory structure.

Third Impact Vector: Corrupted .skill Deliverables to Customers

Because the installed skill files on the host are never updated, when a Cowork session packages a .skill file for distribution, it reads from the mounted host path (which contains the old, unedited files) rather than the VM's working copy where edits were actually made. This means:

1. User edits a skill in the VM (changes are correct in the VM's working directory)
2. User asks to package and export a .skill file
3. The packaging step reads from the host-mounted skill directory — which still has the old version
4. The exported .skill file contains stale, pre-edit content
5. User delivers this to customers believing it contains their edits
6. Customers receive broken/outdated skills

This is a supply chain integrity issue — the user has unknowingly distributed incorrect skill packages to paying customers over multiple weeks.

Why This is P0

1. Silent data loss — No error, no warning. User believes edits are saved.
2. Cascading impact — Every scheduled task that depends on the edited skill breaks.
3. Weeks of user time wasted — Debugging skill logic when the real problem is the installer.
4. No discoverability — Only discovered by accident when grep showed missing content.
5. Core workflow broken — Editing skills is a fundamental Cowork operation. If "Save and Replace" doesn't work, the entire skill iteration loop is broken.
6. Customer-facing impact — Exported .skill files contain stale content, meaning customers receive broken deliverables. This is a supply chain integrity failure.

Related Issues

• #26172 — Skills not loading to Claude Cowork on Mac
• #26254 — SKILL.md files not mounted in container
• #26998 — Skills not saving/loading on Windows

Additional Context

The third screenshot shows that today's run (Apr 11 at 3:09 AM) is STILL prompting for permission to run commands — despite the skill being edited to include an "Autonomous operation" section that pre-approves all access. This confirms the edit was never installed.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

Code 2.1.92. (The Cowork VM doesn't expose a separate Cowork version number — it runs on Claude Code 2.1.92 under the hood, with CLAUDE_CODE_ENTRYPOINT=local-agent. The Claude Desktop app version would be visible from the macOS app menu (Claude → About Claude). For the bug report, I'd reference it as Claude Desktop (Cowork mode), powered by Claude Code 2.1.92.)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Why This is P0

Silent data loss — No error, no warning. User believes edits are saved. Cascading impact — Every scheduled task that depends on the edited skill breaks. Weeks of user time wasted — Debugging skill logic when the real problem is the installer. No discoverability — Only discovered by accident when grep showed missing content. Core workflow broken — Editing skills is a fundamental Cowork operation. If "Save and Replace" doesn't work, the entire skill iteration loop is broken. Customer-facing impact — Exported .skill files contain stale content, meaning customers receive broken deliverables. This is a supply chain integrity failure.