[bug]: skill update fails with EPERM rename on Windows when the skill dir is locked (agent junction target)
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 65/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- node.js, typescript
Research direction
The issue is in the skill update logic, likely in a file handling the rename operation for skill directories. Look for the code that performs the rename (e.g., in a skill manager or updater module) and the error handling for EPERM on Windows. The fix involves changing the update strategy to avoid renaming a locked directory, perhaps by replacing contents in place or using a copy+delete fallback. Test the fix on Windows with an agent holding a directory handle to ensure the update succeeds.
Written by the indexing model from the issue text.
Description
CLI version
2.0.1
Skill version (optional)
1.28.0
Node version
v24.18.0
OS
Windows 10.0.26200 (x64), PowerShell 5.1
Region
cn
Command to reproduce
bl skill update
Expected behavior
All installed skills are updated to the latest registry version, keeping the CLI and its skills version-aligned.
Actual behavior
bl skill update renames each installed skill directory to <name>.old-<timestamp> before writing the new version. On Windows, when another process (the agent host) holds a directory handle on the skill dir, that rename fails with EPERM. 7 of 10 installed skills were left at 1.28.0 while the CLI had already been auto-upgraded to 2.0.1, and the command exited with code 1.
Full output
Error: 7 skill(s) failed to update
Hint: Check the reason for failed skills in the output; network failures can be retried with bl skill update
Exit code: 1
{
"registry": "https://bailian-wiki.oss-cn-hangzhou.aliyuncs.com/skills",
"skills": [
{
"name": "bailian-cli",
"status": "failed",
"reason": "EPERM: operation not permitted, rename 'C:\\Users\\<user>\\.bailian\\skills\\bailian-cli' -> 'C:\\Users\\<user>\\.bailian\\skills\\bailian-cli.old-1790157014446'"
},
{
"name": "bailian-gen",
"status": "failed",
"reason": "EPERM: operation not permitted, rename 'C:\\Users\\<user>\\.bailian\\skills\\bailian-gen' -> 'C:\\Users\\<user>\\.bailian\\skills\\bailian-gen.old-1790157014456'"
},
{
"name": "bailian-protocol",
"status": "failed",
"reason": "EPERM: operation not permitted, rename 'C:\\Users\\<user>\\.bailian\\skills\\bailian-protocol' -> '...old-1790157015136'"
},
... (same EPERM rename failure for bailian-finetune, bailian-managed-agent, bailian-sandbox, bailian-docs-llm-wiki)
]
}
JSON error (optional)
Already tried
- bl update and skill version aligned with CLI
- bl auth status OK for this command
- Different network / region — still reproduces
How often does this happen?
Always
How was bl invoked?
Agent (Cursor, Claude, etc.)
Notes (optional)
Isolation performed on the same machine (all reproduced, 2/2 runs):
- ACLs are fine (FullControl); renaming a brand-new dir in the same parent -> OK
- Copying a skill dir and renaming the copy -> OK
- Creating a new junction to a fresh dir and renaming its target -> OK (the junction itself does not block)
- Renaming the pre-existing skill dirs -> Access denied (reproducible)
- Creating/deleting files inside the locked dir -> OK
- Windows Restart Manager reports no open FILE handles (directory handles are not visible to it)
=> consistent with a directory handle held by another process.
Workaround that works: release the handles (restart the agent host) and run bl skill update inside that window -> all 7 skills updated successfully (exit 0).
Suggested fix:
- Do not rely on renaming the target directory: replace contents in place, or fall back to copy+delete with retry on EPERM/EBUSY.
- Or detach the agent-dir junction/link before the swap, then re-link after.
- On failure, emit an actionable hint (e.g. close agent hosts holding the skill dirs).
Repro details: skills are stored once at C:\Users<user>.bailian\skills<name> and junctioned into the agent skill root C:\Users<user>.openclaw\skills<name>.
Related: #200 (opt-out of silent auto-update + automatic skill sync) - same code path.
Redaction: API keys/tokens removed; username replaced with .
- Dominant language
- TypeScript
- Stars
- 333
- Forks
- 28
- Avg merge
- 1d 8h
- Merged PRs (30d)
- 38
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from modelstudioai/cli
-
[bug] bl update: darwin-arm64 binary ships invalid ad-hoc signature, killed by macOS (Killed: 9) Open
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
modelstudioai/cli#223 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 65/100
modelstudioai/cli#224 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 72/100
modelstudioai/cli#211 ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
modelstudioai/cli#202 · 1 comment · 1 reaction ·
-
Difficulty 4/5 3-5 days Newbie friendliness 63/100
modelstudioai/cli#200 · 1 comment ·
All issues in modelstudioai/cli
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
bug v2
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
modelcontextprotocol/inspector#2458 · 1 comment ·
-
Difficulty 1/5 Under an hour Newbie friendliness 75/100
railmapgen/rmp-gallery#4068 ·
-
Mend: dependency security vulnerability status: needs triage 🕵️♀️
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
carbon-design-system/ibm-products#9907 ·