Permissions & Cost

The permission model

When the agent wants to do something that touches your machine — edit a file, overwrite one, or run a shell command — that call is intercepted before it executes. BharatCode resolves the call to one of three verbs:

• ask — pause and prompt you to approve or reject the call. This is the default for the actions that change your system.
• allow — run the call immediately, without interrupting you.
• deny — refuse the call outright. The agent is told it was denied and works around it rather than waiting on you.

Read-only tools — view, ls, glob, grep, diagnostics, todo, and the web tools (web_fetch, web_search) — do not change anything on disk, so by default they run without asking. The four tools that do change your machine — edit, multiedit, write, and bash — are the ones the gate exists for. See Built-in Tools for the full read-only-vs-gated breakdown.

Remembering an answer: scopes

When BharatCode asks and you approve, you don't have to re-answer the same question every time. Each approval can be remembered for a chosen scope, so a one-time “yes” can become a standing rule:

• once — apply to just this call. The next call asks again.
• session — remember for the rest of the current session. A new session starts fresh.
• project — remember for this project. The decision sticks the next time you open BharatCode in the same repository.
• forever — remember globally, across every project on this machine.

Approval modes

The approval mode sets the overall posture — how eager BharatCode is to ask before acting. Switch modes mid-session with the /permissions slash command, or set a default in config. There are three:

• read-only — only the read-only tools auto-run. Anything that would change a file or run a command is held back. Use this to let the agent explore and explain a codebase without touching it.
• auto — the default. Read tools run freely; the system-changing tools ask, and your answers are remembered per the scope you choose. This is the everyday balance of speed and control.
• full — allow everything, no prompts. This is the same posture as the --yolo flag: the agent edits, writes, and runs shell commands without stopping to ask.

Set the mode interactively from inside the TUI:

/permissions read-only/permissions auto/permissions full

Or pick a default in config so every session starts in the posture you want. mode sits inside the permissions block:

{  "permissions": {    "mode": "auto",          // read-only | auto | full    "view": "allow",         // read tools: safe to auto-run    "grep": "allow",    "edit": "allow",         // exact match — auto-approve every edit call    "multiedit": "allow",    "write": "ask",          // ask before creating or overwriting files    "bash": "ask"            // ask before each shell command  }}

Deny-list and auto-approve patterns

Beyond the mode, you can pin individual tools to a verb in the permissions block. Each key is a tool name and each value is ask, allow, or deny. An allow entry is an auto-approve rule for that tool; a deny entry is a deny-list entry that refuses it. Patterns match in two forms:

• Exact match — a bare tool name like edit or bash matches calls to exactly that tool.
• Wildcard — <tool>:* (for example bash:*) matches all calls to that tool.

A common “trusted repo, no network” setup auto-approves edits while denying the shell and web tools entirely:

{  "permissions": {    "mode": "auto",    "bash": "deny",          // exact: refuse the bash tool outright    "web_fetch": "deny",     // and keep this repo off the network    "web_search": "deny",    "edit": "allow"          // but let edits through without asking  }}

Because the project file is merged on top of the global one, a deny in ./.bharatcode.json is a clean way to make a single repository stricter than your machine-wide default — see Configuration for the global-then-project merge order.

The INR cost ledger

Every call to a model has a price, and BharatCode tracks it in rupees as you go. After each call the ledger records the cost of that turn in INR, accumulates it into your running spend, and surfaces the total so cost is never a surprise at the end of the month. This is what “data — and accounting — stays in India” looks like in practice: a transparent, rupee-denominated tally rather than an opaque dollar bill later.

The monthly budget gate

Set a monthly ceiling and BharatCode enforces it. The budget block in config holds a single number, your limit in rupees:

{  "budget": {    "monthly_limit_inr": 2000  }}

As spend climbs toward the limit the gate watches the running total; once the month's spend reaches monthly_limit_inr, the budget gate stops further calls so you can't blow past it unintentionally. The counter resets with the calendar month.

Inspect spend and the remaining allowance from the command line at any time:

$ bharatcode stats$ bharatcode budget

bharatcode stats reports your usage and accrued cost, and bharatcode budget shows where you stand against the monthly limit. Inside the TUI, the /budget slash command shows the same figures without leaving your session.

Spend in the TUI footer

You don't have to run a command to see where you are. The TUI footer shows your spend as you work, so the rupee total is always in view while the agent runs — roughly:

deepseek · auto · ₹12.40 spent · ₹2000 budget

Putting it together

Permissions and cost are the two guardrails that let you hand work to an autonomous agent without losing the wheel. A typical setup keeps auto mode with the system-changing tools on ask, auto-approves the edits you trust per project with an allow rule, and pins a monthly INR budget so an over-eager session can never run up an unbounded bill.

• Tighten a single repo with a deny rule or read-only mode in ./.bharatcode.json.
• Switch posture on the fly with /permissions, and drop into --yolo only for a sandbox.
• Watch the footer, check bharatcode budget, and let the gate stop you at the limit.