Questions & answers

No. deny wins over allow regardless of the scope it is written in (user, project or local). With this in the project .claude/settings.json, a broad Read allow in someone's settings.local.json still cannot read .env:

{
  "permissions": {
    "deny": ["Read(./.env)", "Read(./.env.*)"]
  }
}

Note that deny rules govern Claude Code's tool calls. Reading through a shell command such as cat .env is a separate rule, and prefix matches like Bash(cat .env:*) are easy to sidestep. For values that truly matter, keep .env outside the workspace or inject secrets at run time from a secrets manager.

Work through these in order.

1. Run /hooks and check the hook is listed. If not, the JSON is invalid (trailing comma, quotes) or the file is in the wrong place (.claude/settings.json or ~/.claude/settings.json).
2. matcher is a regular expression on the tool name: Edit|Write|MultiEdit for file edits, Bash for commands. Check the event name spelling too (PreToolUse / PostToolUse).
3. Make sure the script is executable (chmod +x), has a shebang line, and that jq is installed. Calling it as bash .claude/hooks/format.sh avoids the permission issue.
4. Start with claude --debug to see each hook's execution, exit code and stderr.

Restart the session after editing settings to be sure the change is loaded.

Yes. The workspace-write sandbox blocks network access by default, so package downloads fail. With the on-failure approval policy Codex asks whether to rerun the command outside the sandbox; approve it and the install goes through. To stop being asked, allow the network in ~/.codex/config.toml:

sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = true

Allowing the network also allows data to leave the machine, so enable it only for repositories you trust. Research-only sessions can stay in read-only.