Summary
Please expand a leading ~/ to the user’s home directory in path-based settings.json
fields — write_file(...), trustedWorkspaces, hook command paths, etc. — so one config
file stays portable across machines, users, and operating systems.
Example — without vs. with ~/ expansion
Without (today) — absolute paths, hardcoded and duplicated per user/OS:
{
"permissions": {
"allow": [
"write_file(/home/alice/.cargo)",
"write_file(/Users/alice/.cargo)"
]
},
"trustedWorkspaces": [
"/home/alice/repo/foo",
"/Users/alice/repo/foo"
]
}
Breaks for any other username, and must be re-edited on every host.
With (requested) — one portable file, no duplication:
{
"permissions": {
"allow": [
"write_file(~/.cargo)"
]
},
"trustedWorkspaces": [
"~/repo/foo"
]
}
The same file works on Linux, macOS, and any username.
Why it matters
- Portability. Configs are commonly synced via dotfile managers (yadm, chezmoi, Stow)
across Linux/macOS and multiple usernames. Absolute paths hardcode both the username and
the home layout (/home/<user>vs/Users/<user>). ~is the universal CLI convention, so users writewrite_file(~/.cargo)and expect
it to match. If~is stored but not expanded, the rule silently becomes a no-op — a
permission that looks granted but never matches.
Requested behavior
- A leading
~/in any permission path resolves to the home directory — so
write_file(~/.kube)matches/home/<user>/.kubeon Linux and/Users/<user>/.kubeon macOS. - Apply it uniformly to all path-bearing fields, including
trustedWorkspaces
(which currently requires absolute paths).
Prior art
Claude Code resolves ~/ to the home directory in its sandbox filesystem rules
…