fix(buzz-dev-mcp): expand leading ~ in read_file/str_replace paths - #6271
fix(buzz-dev-mcp): expand leading ~ in read_file/str_replace paths#6271salman1993 wants to merge 1 commit into
Conversation
resolve_path only handled absolute paths and workspace-relative joins, so a user-named tilde path like `~/.claude/skills/x` fell through the relative branch and resolved under the workspace root (`/app/~/.claude/...`), which never exists. The shell tool expands `~` via bash, so the file tools diverged from it — agents in the PR #6261 named-path benchmark all hit this and had to recover. Expand a leading `~` (bare `~` or `~/...`) to the user home directory at the single chokepoint resolve_path, matching shell semantics. Home is read from $HOME (%USERPROFILE% on Windows). `~user` is intentionally left untouched — it needs a passwd lookup and is out of scope, consistent with the conservative posture for un-mappable MSYS forms. expand_tilde takes home as a parameter so it stays pure and testable without mutating the process environment. Closes #6270 Co-authored-by: Salman Mohammed <smohammed@squareup.com> Signed-off-by: Salman Mohammed <smohammed@squareup.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2ac0cb227a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| #[cfg(windows)] | ||
| let var = std::env::var_os("USERPROFILE"); |
There was a problem hiding this comment.
When a Windows launch environment defines HOME differently from USERPROFILE, Git Bash expands ~ using HOME, but this helper always chooses USERPROFILE. This is a supported configuration because buzz-agent/src/mcp.rs preserves both variables when spawning MCP servers, so shell and read_file/str_replace can target different files or the file tools can fail despite the shell path existing. Prefer HOME when present—translating an MSYS-form value if necessary—and fall back to USERPROFILE.
Useful? React with 👍 / 👎.
1 participant
Problem
resolve_path(crates/buzz-dev-mcp/src/paths.rs) only ever treats a path as absolute or joins it onto the workspace root. A user-named tilde path like~/.claude/skills/context-health-check/SKILL.mdis not absolute, so it resolves to<workdir>/~/.claude/...(e.g./app/~/.claude/...), which never exists. Theshelltool expands~via bash, so the file tools diverged from it.Surfaced in the PR #6261 named-path benchmark: all five agents initially passed a literal
~toread_file, which resolved incorrectly under/app/~. They recovered, but the ergonomics are wrong.Fix
Expand a leading
~(bare~or~/...) to the user home directory at the single chokepointresolve_path, matching shell semantics. Home is read from$HOME(%USERPROFILE%on Windows). Bothread_fileandstr_replaceroute throughresolve_path, so both are fixed.~user(another user home) is intentionally NOT handled — it needs a passwd lookup and is out of scope, consistent with the conservative posture for un-mappable MSYS forms already in this file.~user...falls through untouched and fails with the clearpath not accessibleerror.expand_tildetakeshomeas a parameter so it stays pure and unit-testable without mutating process environment; env lookup lives in a thinhome_dir()helper.~support.Tests
expand_tilde_forms: pure coverage of non-tilde passthrough,~user/~foopassthrough, bare~,~/rest, and unset/empty home.resolve_path_expands_tilde_against_home: end-to-end through the realhome_dir()env read (creates a marker file under$HOME, skips cleanly if no home).cargo test -p buzz-dev-mcp— 98 passed, 0 failed.cargo clippy -p buzz-dev-mcp --all-targetsclean.Closes #6270