← Reference

Permission modes

Top-level posture for tool calls.

Full notes from the app

Stored in the permissions kvstore namespace; survives restarts. Switch live via /permissions <mode> (the rule editor on no-args) or the in-app ask gate. Set it at launch with kcode --permission-mode <default|accept-edits|bypass|plan> or --bypass-permissions (which wins if both are given) — the launch mode applies to sessions this window spawns, with a confirmation line in the chat. Shell commands that edit one file in place (sed -i, perl -pi) ask as the file write they are — the ask names the target file, edit-allow rules apply, and AcceptEdits auto-allows them like any edit; multi-file or dynamic targets still ask as command execution. Tools whose registry descriptor declares them read-only — pure observation: shell_plan, shell_status, LSP queries, memory recalls — classify as reads and auto-allow like fs_read instead of asking (#56); mutating tools keep the ask gate. Tools declared internal (2026-07-27) — the agent's own bookkeeping, mutating only kcode-managed session state; today exactly the task/todo list — are auto-granted in every mode ahead of the rule list (a deny rule can't target them), so bookkeeping never raises a prompt even in an untrusted project. Confirming Deny on the ask gate arms an optional feedback line in the composer — Enter denies with that reason handed back to the agent (reject-with-feedback, R#45); Esc backs out to the choice list.

6 entries · kcode 0.4.0

6 shown
ModeAllowsUse it for
DefaultRead + write (rules enforced)Normal interactive use. Reads — including tools whose descriptor is read-only — auto-allow; rules can deny specific tools/paths; ask gate triggers for risky ops.
PlanRead-only (reads + grep + web)Planning & analysis. No writes, no exec, no subagent spawns. The GET-class web reads (web_fetch, web_search) are allowed without asking — they're part of the read envelope — and a UrlHostGlob deny rule still blocks its hosts.
AcceptEditsRead + write + executeScripting & batch ops. Skips prompts for known-safe patterns; still subject to deny rules.
BypassEverything (no ask gates)Trusted automation. All tools auto-allow after first ask resolution; deny rules still enforced.
The ask dialogAllow once / Allow always (this tool, this project) / DenyThe interactive gate a risky tool call raises (2026-08-01 shape): exactly three choices with explicit wire indices — Allow once, Allow always (persisted as a ProjectAlways rule for this tool in this project), Deny. Interactive bash asks show the planner's evidence, not just the command string: the resolved binary, argv, side-effect class, and glob counts. Bash rules classify per pipeline stage, so a safe first stage (e.g. ls … |) no longer taints the whole command into an ask. A turn parked on an open ask is still interruptible — Esc denies it (2026-08-06) — and the chat's working strip names the park (tool · agent · how long). If an 'Allow always' rule fails to persist, the failure surfaces as an in-transcript notice instead of vanishing.
Project trustUntrusted ⇒ project .kcode + .mcp.json ignoredNew-session spawns and resumes into other projects gate the same way (Esc there cancels the action instead). Headless kcode -p never shows a dialog: an untrusted project runs untrusted with a stderr notice. Granting trust live-re-applies the boot project's config/commands/skills/theme without a relaunch; deep [section] config still needs one. The client dialog is consent UX — the daemon re-checks trust at every session spawn, so the gate holds regardless of which client asks.