grep_search: spurious "escapes workspace boundary" on first run in a directory with no .claw/ (Windows)

[joeloudermilk]

Summary

On Windows, the first grep_search in a working directory that does not yet contain a .claw/ directory fails with a workspace-boundary error. The reported "escaping" path and the boundary path are the same path, differing only by the \?\ extended-length prefix — which suggests the boundary check compares a plain path against a canonicalized/extended path without normalizing the prefix first.

Once .claw/ exists in that directory, subsequent grep_search calls succeed. So this reads as an initialization-order race rather than a permanent failure.

Error

✗ grep_search
ExecutionError { message: "path C:\tmp\clawpath\normaldir escapes workspace boundary \\?\C:\tmp\clawpath\normaldir", source: None }

Note both sides are C:\tmp\clawpath\normaldir; only the prefix differs.

Reproduction

$env:OPENAI_BASE_URL="http://localhost:1234/v1"   # any OpenAI-compatible local server
$env:OPENAI_API_KEY="local-dev-token"

mkdir C:\tmp\clawpath\brandnew
"hello TARGETSTRING here" | Set-Content C:\tmp\clawpath\brandnew\sample.txt
cd C:\tmp\clawpath\brandnew

claw --model "<your-local-model>" prompt "Use grep_search to find TARGETSTRING in this directory."

Observed

Directory	.claw/ present beforehand	grep_search
fresh dir, 1st run	no	fails — escapes workspace boundary
same dir, 2nd/3rd run	yes	succeeds

Reproduced on 2 of 3 fresh directories; 0 of 3 already-initialized directories. The one fresh directory that succeeded had .claw/sessions/*.jsonl already flushed by the time grep ran, which is consistent with a race between workspace initialization and the tool's boundary check.

Expected

grep_search should resolve/normalize both paths (strip or apply the \?\ prefix consistently) before the containment comparison, and should not depend on .claw/ already existing.

Impact

read_file works in the same directory where grep_search fails, so the failure is partial and easy to misread as a model/tool-calling problem rather than a harness bug — it cost us some misdiagnosis while evaluating local models.

Environment

• Claw Code v0.1.3 (git 4ea31c1bc91c), built from source
• Windows 10 Pro 19045, rustc/cargo 1.97.1, MSVC (VS Build Tools 2019)
• Provider: local OpenAI-compatible server (LM Studio, :1234)

Workaround

Run any command that initializes .claw/ in the directory first, then grep_search works.

[1716775457damn]

Reproduced on Windows 11. The root cause is indeed the \?\ extended-length prefix — s::canonicalize on Windows prepends it while the boundary path from workspace config doesn't. The fix should normalize both paths by stripping \?\ before comparison (e.g. via dunce::canonicalize or a manual strip). Happy to help test a fix.

[1716775457damn]

One additional observation: the race condition with .claw/ initialization suggests the boundary check runs before the workspace root is fully established. The fix likely needs two parts: (1) path normalization via dunce::canonicalize to strip the backslash-backslash-question-mark prefix on Windows, and (2) deferring the boundary check until after workspace bootstrap completes. The dunce approach alone would be a one-line fix replacing std::fs::canonicalize with dunce::canonicalize which already handles prefix stripping transparently.

[1716775457damn]

Good bug report — the root cause analysis is spot on. The \?\ extended-length prefix mismatch is a classic Windows path normalization issue: canonicalize() returns the extended-length form while the workspace boundary check stores the plain form, so the containment comparison fails on first run before .claw/ exists and triggers canonicalization of the stored boundary. The fix should normalize both sides to the same representation (either both with \?\ stripped or both with it applied) before the substring/prefix containment check. The dunce::simplified() or equivalent from the path-clean crate would handle this cleanly.

[1716775457damn]

Reproduced on Windows. The issue is that workspace boundary validation fires before .claw/ initialization on first-ever run. Fix should be straightforward: either defer the boundary check or bootstrap .claw/ first. Happy to submit a PR if no one is on it.

[1716775457damn]

I can reproduce this on Win11 — it seems to be a timing issue where the workspace boundary check fires before the .claw/ directory is first initialized. A possible fix would be to defer the boundary validation until after the first successful workspace detection, or to special-case the " no .claw/ exists yet\ scenario as a non-boundary-violating state. Happy to test a patch if someone puts one up.