Sandbox policy does not match settings.json: allowWrite glob refused, excludedCommands intermittently proxied

Summary

The effective sandbox policy does not match ~/.claude/settings.json. Two separate entries in that file are not in force, and one of them started working part-way through a single session without the file changing.

Reproduction

~/.claude/settings.json contains:

{
  "sandbox": {
    "enabled": true,
    "excludedCommands": ["codeassembly *", "gh *"],
    "filesystem": {
      "allowWrite": ["~/repos/vaults/*-kb", "~/repos/vaults/*-kb.*"]
    }
  }
}

With that in place, in a sandboxed Bash tool call:

touch ~/repos/vaults/coding-kb/probe

fails with Operation not permitted, although ~/repos/vaults/*-kb is listed under sandbox.filesystem.allowWrite. A plain-directory equivalent under an allow-listed path succeeds, so the glob entry specifically appears not to be honored.

Second symptom, same session

gh * is listed under sandbox.excludedCommands, so gh should bypass the filtering proxy entirely. Twice in one session, gh pr create and gh issue create failed with:

Post "https://api.github.com/graphql": tls: failed to verify certificate: x509: OSStatus -26276

REST calls through the same binary (gh api repos/OWNER/REPO/pulls --method POST) succeeded at the same time, which is consistent with a filtering proxy allowing REST paths and refusing /graphql. About ten minutes later, in the same session with no configuration change, gh pr create-class commands (gh pr list, gh pr view, gh api graphql) all succeeded. The failure has not reproduced since, including under the compound-command and command-substitution shapes that originally triggered it.

Notes

• ~/.claude/settings.json was last modified 17 days before the session; it did not change during it.
• No managed-settings.json, no managed-settings.d, and no policy-limits.json exist on the machine, so nothing is overriding user settings from those layers.
• The sandbox policy description supplied to the model changed part-way through the session: its second form listed ~/repos/vaults/*-kb paths under allowWrite that its first form did not, while the settings file was unchanged throughout. The vault write was refused both before and after that change.

Impact

Sandbox settings cannot be relied on. A path declared writable is refused, and a command declared exempt from sandboxing is intermittently proxied, so an agent hits failures that the configuration says should not occur and cannot tell a policy error from a genuine one.

Environment

• macOS 15 (Darwin 25.6.0), Claude Code CLI, gh 2.98.0.