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 <project>/.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