Sandbox: Edit-allow-rule globs merge into sandbox.filesystem.allowWrite but seatbelt ignores mid-path globs (silent Edit/Bash inconsistency)

Summary

On macOS, permission allow rules with mid-path globs (e.g. Edit(//Users/me/Code/*/.claude/worktrees/**)) are merged into the sandbox filesystem write configuration, but the generated seatbelt profile does not honor mid-path glob patterns. The result is a silent inconsistency: Claude's Edit/Write tools can modify files under the matched paths, while Bash subprocesses (npm, git, build scripts) are denied with EPERM on the exact same paths.

Repro

1. In ~/.claude/settings.json, add an Edit allow rule with a mid-path glob, e.g. Edit(//Users/<me>/Code/*/.claude/worktrees/**).
2. Start a session in a repo matching the glob; create <repo>/.claude/worktrees/wt (e.g. via git worktree).
3. Edit tool writes inside the worktree succeed.
4. Any Bash subprocess write to the same directory (touch, npm install, git commit) fails with Operation not permitted.
5. Replacing the glob with a literal per-repo path (//Users/<me>/Code/myrepo/.claude/worktrees/) in sandbox.filesystem.allowWrite makes Bash writes succeed — confirming the glob is the only difference.

Why it matters

• Users cannot see the inconsistency: the config accepts the glob, Edit honors it, and only subprocess writes fail — mid-task, with generic EPERM errors far from the cause.
• Any workflow standardizing per-repo writable subdirectories (git worktrees under <repo>/.claude/worktrees/ being the natural case for this CLI) requires a manually maintained literal entry per repo.

Suggested fix

Either honor mid-path globs at profile build time by expanding them against existing matching directories (re-expanding per session start would cover newly created repos), or reject/warn on glob patterns that the seatbelt layer will not enforce, so the config surface and the enforcement surface agree.

Observed on Claude Code on macOS (darwin 25.x) with the default sandbox enabled.