Profiles

BharatCode builds its effective config by merging your global config with any project config. A profile adds a third, optional layer on top of that merge. You opt into a profile per invocation with --profile <name>, so the same machine and the same project can behave very differently depending on which profile you select — strict and read-only for reviewing untrusted code, or wide open for trusted automation.

How profiles fit the config merge

Without a profile, your effective config is the global config merged with the project config:

• ~/.config/bharatcode/config.json — your global base config.
• ./.bharatcode.json — the project config, merged on top of the global one.

When you add --profile <name>, BharatCode loads ~/.config/bharatcode/<name>.json and overlays it last. The profile is the highest-priority layer, so any field it sets overrides the same field from the global and project configs. Fields the profile leaves out fall through to whatever the merge already produced.

~/.config/bharatcode/config.json      # 1. global base./.bharatcode.json                    # 2. project overrides global~/.config/bharatcode/<name>.json      # 3. --profile <name> overrides both

Two common profiles

The clearest way to think about profiles is by intent. Here are two profiles that pull in opposite directions — a cautious one for reading code you do not trust, and a permissive one for unattended scripting.

A locked-down review profile

When you are exploring an unfamiliar repository or reviewing a pull request, you want the agent to look but not touch. A review profile pins the approval mode to read-only and denies the tools that mutate files or run shell commands, so nothing can be changed on disk no matter what the model decides to do.

{  "approval_mode": "read-only",  "permissions": {    "edit": "deny",    "multiedit": "deny",    "write": "deny",    "bash": "deny"  }}

Because the profile is the last layer to merge, this read-only mode wins even if your global or project config set a more permissive mode. The view, ls, glob, grep, and diagnostics tools still work, so you can read and search the codebase freely while edits and shell access stay blocked.

A full-access scripting profile

At the other extreme, an automation or scripting profile assumes you already trust the workspace and want the agent to run without stopping for approvals. It sets the approval mode to full and can point at a fast, cheap model for batch work.

{  "approval_mode": "full",  "model": "deepseek/deepseek-chat"}

Selecting a profile

Pass --profile <name> to any invocation. It works for the interactive TUI and for headless runs alike.

$ bharatcode --profile review

$ bharatcode run --profile review "Summarize what changed in this PR"

The scripting profile pairs naturally with headless automation. Combine it with --json for an NDJSON event stream and --output-last-message to capture the final answer to a file:

$ bharatcode run --profile scripting --json \$   --output-last-message ./result.txt \$   "Run the test suite and fix any failing tests"

Precedence and partial overlays

A profile does not have to be a complete config. It only needs the fields you want to override; everything else is inherited from the merge underneath it. That makes profiles small and focused — they describe a posture, not a whole configuration.

Suppose your global config selects a default model and your project config defines providers and a monthly budget. A review profile that sets only the approval mode and a few permission denials changes the agent's posture while leaving your model, providers, and budget untouched:

model:        from global config        (profile does not touch it)providers:    from project config       (profile does not touch it)budget:       from project config       (profile does not touch it)approval_mode: read-only                (profile wins)permissions.edit / write / bash: deny   (profile wins)

Profiles cover config-level overrides. For instructions that travel with a repository rather than your machine, see AGENTS.md, and for the full list of config fields you can set in a profile, see Config files.