Windows workspace path leak / normalization causes false "outside workspace" errors

[utkuvibing]

Summary

On Windows, Command Code tried to access an unrelated macOS-style path (/Users/matthiaslaug/dev/relay) even though the active workspace was C:\root\projects\Relay.

After I corrected the workspace path, it then converted the valid Windows path to /c/root/projects/Relay, which the permission layer also treated as outside the allowed workspace.

This blocks normal repository tool calls and looks like a stale/default workspace path leak plus inconsistent Windows/POSIX path canonicalization.

Expected Behavior

Command Code should use the currently opened workspace (C:\root\projects\Relay) and repository-relative paths.

Equivalent Windows/POSIX representations of the same workspace should not be rejected as outside the workspace, and unrelated stale paths should never appear in tool calls.

Actual Behavior

On the first repository read, Command Code attempted to access:

/Users/matthiaslaug/dev/relay

The permission layer correctly rejected it because the allowed workspace was:

C:\root\projects\Relay

After I explicitly told Command Code to use the correct workspace, a later shell command used:

/c/root/projects/Relay

This was again rejected as outside the workspace because the permission system only recognized the native Windows path.

Steps to reproduce the issue

1. Open Command Code on Windows with the workspace C:\root\projects\Relay.
2. Start a new session and ask the agent to inspect/recon the current repository.
3. Observe the first tool call attempting to read /Users/matthiaslaug/dev/relay.
4. Reject the permission request and tell the agent the correct workspace is C:\root\projects\Relay.
5. Let it continue repository reconnaissance.
6. Observe a subsequent command using /c/root/projects/Relay.
7. The permission layer rejects that path as outside the workspace as well.

Command Code Version

v1.37.0

Operating System

Windows

Terminal/IDE

Windows Terminal-Herdr

Shell

Powershell

Session file (optional)

No response

Fix prompt (optional)

Please canonicalize workspace paths consistently on Windows before permission checks, and ensure tool calls derive their working directory from the active workspace rather than any stale/default path.

Native Windows paths such as C:\root\projects\Relay and equivalent normalized representations should resolve to the same allowed workspace.

Additional context

Screenshots attached showing both failures.

The /Users/matthiaslaug/dev/relay path has no relation to my machine or project, which is why I suspect stale/default path metadata may be leaking into the tool/harness context.

The second failure suggests the permission layer and shell/path normalization layer disagree on Windows path identity.

[MaedahBatool]

@naymurdev tagging you