ultraworkers / ultraworkers/claw-code

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

Open
#3,278 9 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
195k
Forks
108k
PR merge metrics
No merged PRs in 30d

Description

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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the Windows fresh-directory case using the grep_search entry point, then trace its workspace-boundary check alongside first-run .claw/ initialization. Done means the first search succeeds in a directory without .claw/ and path containment works consistently for plain and extended-length Windows paths.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
operating-systems, tooling
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.