Problem
The dev-mcp read_file / str_replace tools do not expand a leading ~. In resolve_path (crates/buzz-dev-mcp/src/paths.rs), a path is only ever treated as absolute or joined onto the workspace root. A tilde path like ~/.claude/skills/x is not absolute, so it resolves to <workdir>/~/.claude/... (e.g. /app/~/.claude/...), which never exists.
Observed in the PR #6261 named-path benchmark: all five agents initially passed a literal ~ to read_file, which resolved incorrectly under /app/~. Every agent recovered, but the tool ergonomics are wrong — the shell tool expands ~ via bash, so the file tools diverge from it.
Fix
Expand a leading ~ (bare ~ or ~/...) to the user home directory ($HOME, %USERPROFILE% on Windows) at the single chokepoint resolve_path, matching shell semantics. ~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.
Problem
The dev-mcp
read_file/str_replacetools do not expand a leading~. Inresolve_path(crates/buzz-dev-mcp/src/paths.rs), a path is only ever treated as absolute or joined onto the workspace root. A tilde path like~/.claude/skills/xis not absolute, so it resolves to<workdir>/~/.claude/...(e.g./app/~/.claude/...), which never exists.Observed in the PR #6261 named-path benchmark: all five agents initially passed a literal
~toread_file, which resolved incorrectly under/app/~. Every agent recovered, but the tool ergonomics are wrong — theshelltool expands~via bash, so the file tools diverge from it.Fix
Expand a leading
~(bare~or~/...) to the user home directory ($HOME,%USERPROFILE%on Windows) at the single chokepointresolve_path, matching shell semantics.~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.