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
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
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 .
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
Expected behavior
All installed skills are updated to the latest registry version, keeping the CLI and its skills version-aligned.
Actual behavior
bl skill updaterenames 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
JSON error (optional)
Already tried
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):
=> consistent with a directory handle held by another process.
Workaround that works: release the handles (restart the agent host) and run
bl skill updateinside that window -> all 7 skills updated successfully (exit 0).Suggested fix:
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 .