Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Gateway exec strips Windows drive letter from workspace path [1 pull requests, 1 comments, 2 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#57358•Fetched 2026-04-08 01:50:40
View on GitHub
Comments
1
Participants
2
Timeline
2
Reactions
0
Author
yackattack22yackattack22
Participants
SnowSky1SnowSky1yackattack22yackattack22
Timeline (top)
commented ×1cross-referenced ×1

Root Cause

This appears to happen at the gateway exec / binary path resolution layer, not from user config. The workspace prefix is being rewritten incorrectly before execution — specifically, the first character of the absolute Windows path (the drive letter) is being consumed or stripped.

The same missing-drive-letter pattern also appeared in automatically-generated allowlist entries:

C:\Users\<user>\:\Users\<user>\AI\system\openclaw
C:\Users\<user>\AI\system\openclaw\:\Users\<user>\AI\system\openclaw

These suggest the drive letter stripping has been happening consistently across multiple exec invocations.

PR fix notes

PR #58040: fix(exec): ignore malformed drive-less windows exec paths

Description (problem / solution / changelog)

Summary

  • Problem: when a malformed Windows executable token like :\Users\... reaches exec resolution, OpenClaw currently treats it as cwd-relative and synthesizes even more broken candidate paths such as C:\workspace\:\Users\....
  • Why it matters: this amplifies the original corruption by polluting approval/audit paths and allowlist metadata with invalid Windows paths.
  • What changed: reject drive-less rooted Windows tokens before relative-path resolution in both executable lookup and allowlist/audit candidate-path fallback helpers.
  • What did NOT change (scope boundary): this PR does not claim to identify the original source of the missing drive letter; it only stops malformed :\... tokens from being expanded into worse derived paths.

Change Type (select all)

  • Bug fix

Scope (select all touched areas)

  • Gateway / orchestration
  • Security / approvals / allowlists

Linked Issue/PR

  • Related #57358

User-visible / Behavior Changes

Malformed drive-less Windows exec tokens are no longer treated as cwd-relative paths during resolution, so OpenClaw will stop generating duplicated invalid audit/allowlist paths from inputs like :\Users\....

Security Impact (required)

  • 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

Repro + Verification

Environment

  • OS: Windows 11
  • Runtime/container: local workspace
  • Integration/channel (if any): gateway exec path resolution

Steps

  1. Resolve an executable token that is already malformed as :\Users\demo\AI\system\openclaw.
  2. Compute the allowlist/audit candidate path with cwd C:\Users\demo\AI\system\openclaw.

Expected

  • OpenClaw should not synthesize a cwd-joined path like C:\Users\demo\AI\system\openclaw\:\Users\demo\AI\system\openclaw.

Actual

  • Covered by the new regression tests.

Evidence

  • Failing test/log before + passing after

Targeted local verification:

  • pnpm test -- src/infra/executable-path.test.ts src/infra/exec-command-resolution.test.ts
  • pnpm exec oxfmt --check src/infra/executable-path.ts src/infra/exec-command-resolution.ts src/infra/executable-path.test.ts src/infra/exec-command-resolution.test.ts

Human Verification (required)

What I personally verified:

  • Reproduced the pre-fix behavior where path.resolve("C:\\Users\\demo\\AI\\system\\openclaw", ":\\Users\\demo\\AI\\system\\openclaw") produced the duplicated malformed Windows path pattern reported in #57358.
  • Verified the new regression tests prevent that expansion in both executable lookup and allowlist-candidate fallback logic.

What I did not verify:

  • The original upstream source that first strips the drive letter from the command token.

Compatibility / Migration

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

Failure Recovery (if this breaks)

  • How to disable/revert this change quickly: revert this PR
  • Files/config to restore: src/infra/executable-path.ts, src/infra/exec-command-resolution.ts

Risks and Mitigations

  • Risk: an intentionally relative path beginning with :\ would now be ignored instead of being resolved against cwd.
    • Mitigation: on Windows this token shape is already invalid as an absolute path and is the exact malformed pattern reported in #57358.

AI-assisted: yes. I verified the change locally and understand the narrowed scope.

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/infra/exec-command-resolution.test.ts (modified, +17/-0)
  • src/infra/exec-command-resolution.ts (modified, +7/-0)
  • src/infra/executable-path.test.ts (modified, +12/-0)
  • src/infra/executable-path.ts (modified, +7/-0)

Code Example

C:\Users\<user>\AI\system\openclaw

---

git --version

---

:\Users\<user>\AI\system\openclaw\git --version

---

C:\Users\<user>\:\Users\<user>\AI\system\openclaw
C:\Users\<user>\AI\system\openclaw\:\Users\<user>\AI\system\openclaw
RAW_BUFFERClick to expand / collapse

Environment

  • OpenClaw version: 2026.3.28
  • OS: Windows 11
  • Gateway mode: local, loopback
  • Exec host: gateway

Problem

On Windows, gateway exec prepends the workspace path to commands, but the drive letter is stripped. This produces malformed command paths and breaks normal exec.

Example

Workspace:

C:\Users\<user>\AI\system\openclaw

Expected command:

git --version

Actual command sent to exec:

:\Users\<user>\AI\system\openclaw\git --version

The leading C from C:\... is dropped, resulting in :\... — which is not a valid path on Windows.

What I tried (none fixed it)

  • Updated safeBins and safeBinProfiles for all common binaries
  • Added explicit pathPrepend with full absolute Windows paths
  • Set security: allowlist and ask: on-miss
  • Cleaned corrupt allowlist entries (which had the same colon-prefix pattern from prior exec attempts)
  • Confirmed on latest version (2026.3.28)

What still works

  • Subagent spawns execute shell commands correctly (no path corruption)
  • Gateway connectivity is fine (agent messaging works)
  • Config validates cleanly (openclaw config validate)

Analysis

This appears to happen at the gateway exec / binary path resolution layer, not from user config. The workspace prefix is being rewritten incorrectly before execution — specifically, the first character of the absolute Windows path (the drive letter) is being consumed or stripped.

The same missing-drive-letter pattern also appeared in automatically-generated allowlist entries:

C:\Users\<user>\:\Users\<user>\AI\system\openclaw
C:\Users\<user>\AI\system\openclaw\:\Users\<user>\AI\system\openclaw

These suggest the drive letter stripping has been happening consistently across multiple exec invocations.

Reproduction

  1. Install OpenClaw on Windows with a workspace on C:\
  2. Configure tools.exec.host: "gateway" (default)
  3. Start the gateway in local/loopback mode
  4. Send any exec command (e.g., git --version) through an agent session
  5. Observe the command path is mangled with :\ prefix instead of C:\

Happy to provide sanitized config snippets or exact logs if helpful.

extent analysis

Fix Plan

To fix the issue of the drive letter being stripped from the command path, we need to modify the pathPrepend configuration to correctly handle absolute Windows paths.

  • Update the pathPrepend configuration to include the drive letter:
tools:
  exec:
    pathPrepend: "C:\\\\\\\\"

Alternatively, you can use a more robust solution by using environment variables to construct the pathPrepend value:

tools:
  exec:
    pathPrepend: "${SYSTEMDRIVE}\\\\"

This will ensure that the correct drive letter is used, regardless of the system configuration.

Verification

To verify that the fix worked, send an exec command through an agent session and check the command path. It should now include the correct drive letter.

  • Example command: git --version
  • Expected output: C:\Users\<user>\AI\system\openclaw\git --version

Extra Tips

  • Make sure to escape backslashes correctly in your configuration files.
  • If you're using a different drive letter for your workspace, update the pathPrepend value accordingly.
  • Consider using environment variables to construct paths and commands to make your configuration more robust and flexible.

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…
#installation#tensor shape#autograd error#model save/load#optimization

Still need to ship something?

×6

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

Back to top recommendations

TRENDING