Docs · Using BetterC0de
Permissions
How BetterC0de surfaces every file edit, shell command and tool call an AI coding agent wants to make, and how to approve, deny or scope them.
Coding agents are only useful when they can touch your files and run commands — and only safe when you can see and control that. BetterC0de puts one permission layer in front of every agent, regardless of vendor.
What triggers a request
- Reading files outside the project, or writing any file
- Running a shell command
- Network access from a tool
- Anything the underlying CLI itself marks as needing approval
Requests show up inline in the conversation with the exact command or path, so you decide with full context.
Ways to answer
| Choice | Effect |
|---|---|
| Allow once | This call only. |
| Allow for this session | Same kind of action, same conversation, until you close it. |
| Deny | The agent is told the action was refused and continues without it. |
Per-provider defaults live under Settings → Providers → Permissions. Keep them conservative on repositories you do not know well.
Reviewing after the fact
Permission is the first gate; the Diff view is the second. Nothing is committed until you commit it. Make it a habit to read the diff before git commit, especially when several agents worked on the same branch.
Provider-side sandboxes
Some CLIs bring their own sandboxing (for example Codex's execution modes). BetterC0de respects those settings and layers its prompts on top — it never loosens what the vendor tool enforces.