[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.
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] 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:
- User edits the skill in a Cowork session
- User packages the skill as a
.skillfile - User installs via "Save and Replace" — appears to succeed
- Scheduled task runs with the old, broken skill definition
- Task fails with errors
- 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
- Have an existing skill installed in Cowork (e.g.,
wiki-curator) - Edit the skill's
SKILL.mdin a Cowork session (add new sections, change content) - Package as
skillname.skill(zip archive withskillname/SKILL.mdinside) - Open the
.skillfile in Claude Desktop - Click "Save and Replace" when prompted
- Observe: UI shows success. No error.
- 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:
- Writing to
~/.claude/skills/(CLI location) instead of the Cowork skills directory - Not overwriting due to a file permission or directory-exists check
- 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:
- User edits a skill in the VM (changes are correct in the VM's working directory)
- User asks to package and export a
.skillfile - The packaging step reads from the host-mounted skill directory — which still has the old version
- The exported
.skillfile contains stale, pre-edit content - User delivers this to customers believing it contains their edits
- 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
- 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
.skillfiles 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:
- User edits the skill in a Cowork session
- User packages the skill as a
.skillfile - User installs via "Save and Replace" — appears to succeed
- Scheduled task runs with the old, broken skill definition
- Task fails with errors
- 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
- Have an existing skill installed in Cowork (e.g.,
wiki-curator) - Edit the skill's
SKILL.mdin a Cowork session (add new sections, change content) - Package as
skillname.skill(zip archive withskillname/SKILL.mdinside) - Open the
.skillfile in Claude Desktop - Click "Save and Replace" when prompted
- Observe: UI shows success. No error.
- 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:
- Writing to
~/.claude/skills/(CLI location) instead of the Cowork skills directory - Not overwriting due to a file permission or directory-exists check
- 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:
- User edits a skill in the VM (changes are correct in the VM's working directory)
- User asks to package and export a
.skillfile - The packaging step reads from the host-mounted skill directory — which still has the old version
- The exported
.skillfile contains stale, pre-edit content - User delivers this to customers believing it contains their edits
- 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
- 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
.skillfiles 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.
<img width="942" height="860" alt="Image" src="https://github.com/user-attachments/assets/78da285e-aca8-4a67-9fd8-34245ca4f6e8" />
<img width="1136" height="924" alt="Image" src="https://github.com/user-attachments/assets/8a760b16-b16c-4f7b-903a-afd42a4f5114" />
<img width="2256" height="692" alt="Image" src="https://github.com/user-attachments/assets/0c88fd89-3792-442d-a2a4-1f7b119ed4ee" />
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗