Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: openclaw skills install` always installs to default agent workspace, ignoring current agent [2 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#56161•Fetched 2026-04-08 01:44:17
View on GitHub
Comments
0
Participants
1
Timeline
7
Reactions
0
Author
langbowanglangbowang
Participants
langbowanglangbowang
Timeline (top)
referenced ×3cross-referenced ×2labeled ×2

openclaw skills install always installs to main agent workspace, ignoring current agent context

Root Cause

Root cause located in src/cli/skills-cli.ts: resolveActiveWorkspaceDir() uses resolveDefaultAgentId() which always returns 'main', ignoring the current working directory.

Fix Action

Fix / Workaround

Workaround: Manually copy skills from ~/.openclaw/workspace/skills/ to ~/.openclaw/workspace-<agent>/skills/

PR fix notes

PR #56243: fix(cli): respect current agent workspace for skills install (#56161)

Description (problem / solution / changelog)

Fixes #56161

Problem

openclaw skills install always installs to the default agent workspace (~/.openclaw/workspace/skills/), ignoring the current working directory. This prevents users from installing skills to sub-agent workspaces.

Steps to Reproduce

  1. Configure multiple agents (e.g., main and writer)
  2. Navigate to writer agent's workspace: cd ~/.openclaw/workspace-writer
  3. Run: openclaw skills install content-writer
  4. Observe skill is installed to ~/.openclaw/workspace/skills/ instead of ~/.openclaw/workspace-writer/skills/

Root Cause

resolveActiveWorkspaceDir() in src/cli/skills-cli.ts always uses resolveDefaultAgentId(config), ignoring the current working directory.

Solution

Check if current working directory is within a configured agent workspace using resolveAgentIdByWorkspacePath(). If yes, use that agent's workspace. Otherwise, fall back to default agent workspace.

Changes

  • src/cli/skills-cli.ts: Updated resolveActiveWorkspaceDir() to detect current agent workspace from cwd
  • Added import of resolveAgentIdByWorkspacePath from ../agents/agent-scope.js

Testing

  • Type check: ✅ Passed
  • Lint: ✅ Passed
  • Manual test: Run openclaw skills install from a sub-agent workspace directory

Branch Info

  • Created from: upstream/main (2026-03-28)
  • Files changed: 1 (src/cli/skills-cli.ts)
  • Lines: +13, -1

Changed files

  • src/cli/skills-cli.ts (modified, +13/-1)

PR #56294: fix(cli): infer skills workspace from cwd

Description (problem / solution / changelog)

Summary

  • Problem: the skills CLI resolved the default agent workspace too aggressively, so running skills commands inside a sub-agent workspace could read or write the wrong workspace.
  • Why it matters: multi-agent setups lose workspace isolation and skills can appear to install into one workspace while skills list still reads another.
  • What changed: infer the active agent from process.cwd() via resolveAgentIdByWorkspacePath(...) before falling back to resolveDefaultAgentId(...), and use that shared resolution for both install/update and list/info/check.
  • Scope boundary: no ClawHub API changes, no payload format changes, no broader workspace-resolution behavior outside the skills CLI.

Change Type

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #56161
  • This PR fixes a bug or regression

Root Cause

  • src/cli/skills-cli.ts previously resolved the workspace from resolveDefaultAgentId(config) alone.
  • That meant commands launched from a sub-agent workspace ignored process.cwd() even when the workspace path mapped to a configured agent.
  • The original PR also left loadSkillsStatusReport() on the default workspace path, which made skills list / skills info / skills check inconsistent with skills install / skills update.

Regression Test Plan

  • Unit test
  • Target file: src/cli/skills-cli.commands.test.ts
  • Scenarios locked in:
    • install uses the cwd-inferred workspace
    • update uses the cwd-inferred workspace
    • list/info/check load status from the cwd-inferred workspace
    • fallback still uses the default workspace when cwd does not map to an agent

User-visible Changes

  • openclaw skills install
  • openclaw skills update
  • openclaw skills list
  • openclaw skills info
  • openclaw skills check

All now prefer the workspace inferred from the current working directory before falling back to the default agent workspace.

Security Impact

  • New permissions/capabilities? No
  • Secrets/tokens handling changed? No
  • New/changed network calls? No
  • Command/tool execution surface changed? No
  • Data access scope changed? No

Verification

  • pnpm test -- src/cli/skills-cli.commands.test.ts

Human Verification

  • Re-landed this as a clean latest-main PR with only the skills CLI change.
  • Verified the cwd-inferred workspace path is used consistently for both write actions and status-report reads in the command tests.

Compatibility / Migration

  • Backward compatible? Yes
  • Config/env changes? No
  • Migration needed? No

Risks and Mitigations

  • Risk: commands launched from unrelated directories must still fall back cleanly.
  • Mitigation: the shared resolver still falls back to resolveDefaultAgentId(...) when cwd inference returns nothing.

Changed files

  • src/cli/skills-cli.commands.test.ts (modified, +93/-4)
  • src/cli/skills-cli.ts (modified, +11/-3)

Code Example

Installation log showing skill installed to main workspace despite running from sub-agent workspace:

$ cd ~/.openclaw/workspace-writer
$ openclaw skills install content-writer
Installing to /home/renfeng/.openclaw/workspace/skills/content-writer...
Installed content-writer@1.0.0 -> /home/renfeng/.openclaw/workspace/skills/content-writer

Expected: ~/.openclaw/workspace-writer/skills/content-writer
Actual: ~/.openclaw/workspace/skills/content-writer
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

openclaw skills install always installs to main agent workspace, ignoring current agent context

Steps to reproduce

  1. Configure multiple agents (e.g., main and writer)
  2. Navigate to writer agent's workspace: cd ~/.openclaw/workspace-writer
  3. Run: openclaw skills install content-writer
  4. Observe skill is installed to ~/.openclaw/workspace/skills/ instead of ~/.openclaw/workspace-writer/skills/

Expected behavior

Skill should be installed to the current agent's workspace based on process.cwd(), not always to the default agent's workspace.

Actual behavior

The skill is installed to the default agent's workspace (~/.openclaw/workspace/skills/) instead of the current agent's workspace (e.g., ~/.openclaw/workspace-writer/skills/), even when running the command from the sub-agent's workspace directory.

OpenClaw version

2026.3.24

Operating system

Windows 11 + WSL2 (Ubuntu 22.04)

Install method

npm global

Model

glm-5

Provider / routing chain

openclaw -> bailian

Additional provider/model setup details

Using bailian/glm-5 model

Logs, screenshots, and evidence

Installation log showing skill installed to main workspace despite running from sub-agent workspace:

$ cd ~/.openclaw/workspace-writer
$ openclaw skills install content-writer
Installing to /home/renfeng/.openclaw/workspace/skills/content-writer...
Installed [email protected] -> /home/renfeng/.openclaw/workspace/skills/content-writer

Expected: ~/.openclaw/workspace-writer/skills/content-writer
Actual: ~/.openclaw/workspace/skills/content-writer

Impact and severity

Affected: Multi-agent setups with sub-agents (e.g., writer, optimizer, etc.) Severity: Medium (blocks proper skill isolation between agents) Frequency: Always (100% of skill installs from sub-agents) Consequence: Skills installed by sub-agents pollute main agent workspace; sub-agents cannot properly manage their own skills

Additional information

Root cause located in src/cli/skills-cli.ts: resolveActiveWorkspaceDir() uses resolveDefaultAgentId() which always returns 'main', ignoring the current working directory.

Suggested fix: Use resolveAgentIdByWorkspacePath(config, process.cwd()) to infer agent from current directory before falling back to default.

Workaround: Manually copy skills from ~/.openclaw/workspace/skills/ to ~/.openclaw/workspace-<agent>/skills/

extent analysis

Fix Plan

To fix the issue, we need to modify the resolveActiveWorkspaceDir() function in src/cli/skills-cli.ts to use the current working directory to infer the agent ID. Here are the steps:

  • Open src/cli/skills-cli.ts and locate the resolveActiveWorkspaceDir() function.
  • Replace the line that uses resolveDefaultAgentId() with a call to resolveAgentIdByWorkspacePath(config, process.cwd()).
  • Use the returned agent ID to construct the correct workspace directory path.

Example code:

// Before
const agentId = resolveDefaultAgentId();
const workspaceDir = path.join(config.workspaceRoot, 'workspace', 'skills');

// After
const agentId = resolveAgentIdByWorkspacePath(config, process.cwd());
const workspaceDir = path.join(config.workspaceRoot, `workspace-${agentId}`, 'skills');

Alternatively, you can use a fallback approach:

const agentId = resolveAgentIdByWorkspacePath(config, process.cwd());
if (!agentId) {
  agentId = resolveDefaultAgentId();
}
const workspaceDir = agentId === 'main' ? 
  path.join(config.workspaceRoot, 'workspace', 'skills') : 
  path.join(config.workspaceRoot, `workspace-${agentId}`, 'skills');

Verification

To verify the fix, follow these steps:

  • Run openclaw skills install content-writer from a sub-agent's workspace directory (e.g., ~/.openclaw/workspace-writer).
  • Check that the skill is installed to the correct directory (e.g., ~/.openclaw/workspace-writer/skills/content-writer).

Extra Tips

  • Make sure to test the fix with different agent setups and workspace directories to ensure it works as expected.
  • Consider adding a test case to cover this scenario to prevent regressions in the future.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Skill should be installed to the current agent's workspace based on process.cwd(), not always to the default agent's workspace.

#installation#agent setup#task chaining#parallel task#integration issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: openclaw skills install` always installs to default agent workspace, ignoring current agent [2 pull requests, 1 participants]