> For the complete documentation index, see [llms.txt](https://docs.codemate.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.codemate.ai/cora-cli/approvals-and-permissions.md). # Approvals and Permissions Nothing changes without you. How approvals, questions, and standing permissions work. ### Approvals: nothing changes without you This is the most important concept in these docs. In **code** mode, every file edit and every command **stops and asks you**: ``` edit src/server.js --- src/server.js +++ src/server.js @@ -12,6 +12,9 @@ + app.use(rateLimit({ windowMs: 60000, max: 100 })) [y] allow [n] refuse ``` | Key | What happens | | ---------------- | --------------------------------------------------------------------------------- | | **y** | Allow this one action. CORA carries on. | | **n** or **Esc** | Refuse it. CORA is told no, and either works around it or explains why it cannot. | **There is no "always" button, on purpose.** A single keypress that grants permanent permission, for every conversation in that project, forever, is not something anyone should be able to press by accident. If you want standing rules, set them deliberately and visibly with `/settings` (below). #### What the request shows you * For a **command**, the exact command line, so you can read it before it runs. * For a **file edit**, the file path and the actual changes, the lines going in and out. "Allow a command?" with no detail is not a decision anyone can make, so CORA never asks it that way. #### Things worth knowing 1. **CORA is frozen while it waits.** The request replaces the prompt, because nothing else can happen until you answer. 2. **Walking away grants nothing.** After five minutes with no answer, the request is **refused** automatically, and CORA says so. 3. **Refusing is a normal thing to do.** It is not an error. CORA is told it cannot do that and carries on, often by telling you why it wanted to. 4. **Pressing Ctrl+C refuses anything outstanding** before stopping the turn. 5. **The three read-only modes never raise these requests**, because they cannot edit or run commands in the first place. *** ### Questions CORA asks you Separately from permission, CORA can ask you a **question**, a real one, when it has hit a decision only you can make. ``` Which should the new endpoint return when the record is missing? › 1 404 with an empty body 2 200 with null 3 something else, let me type it ↑↓ move · enter answer · esc skip ``` | Key | What it does | | --------- | ------------------------------------------------------ | | **↑ / ↓** | Move between the options | | **1...9** | Jump straight to an option once you have read the list | | **Space** | Tick an option when more than one answer is allowed | | **Enter** | Answer | | **Esc** | Decline: CORA carries on without your input | **You can always answer in your own words.** The last option on every question lets you type a free-text answer instead of picking one. Declining is a real choice, not a failure CORA continues with what it has. Plan mode uses questions most: it asks about the decisions that would change the plan, and works out the facts about your code by reading it rather than by asking you. *** ### Standing permissions (`/settings`) If a certain kind of approval comes up constantly say, you always want `git status` allowed and never want anything starting with `rm` set a standing rule instead of answering every time. Type `/settings`: ``` Permissions, this project › Change my files ask Run commands ask Reach outside this project ask Open my files allow Find files by name allow Search inside files allow Open a web page ask Search the internet ask tab cycles allow · ask · deny · shift+tab goes back enter opens the rules for one tool · esc closes ``` | Key | What it does | | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **↑ / ↓** | Move between tools | | **Tab** | Cycle that tool between **allow**, **ask**, and **deny** | | **Enter** | Open one tool's detailed rules. Only the four that take patterns have any changing files, running commands, reaching outside this project, and opening files. | | **Esc** | Close the screen | Inside a tool's own rules: | Key | What it does | | ---------- | --------------------------------------------------------- | | **Tab** | Cycle the verdict for the highlighted rule | | **Ctrl+A** | Add a rule, for example `git *` → allow, or `rm *` → deny | | **Ctrl+D** | Remove a rule | | **Esc** | Go back | #### Four things to understand about this screen 1. **Rules apply to this project only.** They are saved in `/.cora-cli/config.json` and never follow you into another project. 2. **Read-only modes are not affected.** Ask, plan, and review still cannot edit or run commands, whatever you set here. A promise a setting can switch off is not a promise. 3. **Changes take effect the next time you start CORA.** While what you have set and what the running agent enforces disagree, the screen says so. Do not assume you have locked something down mid-session. 4. **`deny` is quieter than you expect.** A denied tool raises no request at all; CORA simply works around it and never tells you it wanted it. Use `deny` for things you genuinely never want (`rm *`, `git push *`), and leave everything else on `ask`. #### Sensible starting policy | Kind of action | Suggested setting | | ------------------------------------------------------ | ---------------------------------------------------------------------------------------- | | Reading and searching files | allow | | Editing and creating files | ask | | Deleting files | ask (never allow) | | Running commands | ask, with narrow allow rules for safe families such as `git status` or your test command | | Anything that reaches the network or an outside system | ask |