permissions-debug

# Permissions Debug (Kode-first, fail-closed) ## Non-negotiables - Do not auto-escalate permissions. If an action would normally require user approval, keep it interactive and explain why. - Prefer **minimal, reversible** permission changes and verify immediately. - In `dontAsk` contexts, treat “would prompt” as **deny** (fail-closed). Do not try to bypass. ## Fast triage (what to check first) 1. **Confirm what is blocked** - Look for the exact tool name and the rejection message. - If the failure is from a subagent, confirm whether the parent context was more restricted. 2. **Inspect approved tools / project allowlist** - Use `SlashCommand` to run `/approved-tools list` and confirm whether the tool (or its rule category) is present. - If the list is unexpectedly long or contains stale entries, remove only the minimum needed with `/approved-tools remove <tool>`. 3. **Check per-command constraints** - Some flows apply `commandAllowedTools` constraints (slash command / skill execution contexts). Confirm the command’s `allowed-tools` frontmatter and whether it should be restrictive. ## Verification loop (keep it tight) - Re-run the exact action that was blocked and confirm: - whether the prompt appears (interactive modes), or - whether the tool is allowed/denied deterministically (headless / `dontAsk`). ## Forensics (when “it should have worked”) - Inspect the latest session artifacts under `~/.kode/` (messages + errors) to confirm what tool call was attempted and why it was denied. - If a background shell was involved, cross-check task output files in `~/.kode/**/tasks/` for the corresponding `bashId`.