Feature Request(antigravity-cli & antigravity 2) : expand ~/ to the home directory in permission-rule paths

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 write write_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>/.kube on Linux and /Users/<user>/.kube on 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

this is a really clean writeup, and ~/ expansion is such a standard convention that not supporting it is an easy trap for silent no-op permissions. hopefully the antigravity team picks this up soon since you already tagged it as a feature request, thats usually how these get triaged.

@Shivam_Singh2 can you forward this to the relevant internal team ?