Security & Permissions

hara runs on your machine with your tools, so it's built to be safe by default and to keep a human in the loop.

Approval modes

| Mode | Behavior | |---|---| | suggest (default) | asks before editing files or running commands | | auto-edit | edits files freely, still asks before running shell commands | | full-auto | runs without prompting (used by -y, cron, and the gateway) |

Set it with --approval, /approval, or hara config set approval <mode>.

Command rules

Pin down exactly which shell commands run unattended with a permissions.json (allow / deny, plus read-only commands that auto-run even in suggest mode):

hara permissions --init             # scaffold a global ~/.hara/permissions.json
hara permissions --init --project   # scaffold .hara/permissions.json (project scope)

Shell sandbox (macOS)

Confine what the shell can touch:

hara --sandbox workspace-write   # writes limited to the working dir
hara --sandbox read-only         # no writes at all

Untrusted content

Output that hara pulls from the outside world — web fetches, file contents — is wrapped and defanged so injected "ignore your instructions" text can't hijack the agent. Sub-agents run read-only by default, closing the approval-gate bypass; the computer (screen-control) tool is never auto-approved.

Secrets

API keys and tokens are stored 0600 (~/.hara/config.json, OAuth token files). Secret-looking files are skipped by the semantic index so keys never land in an embedding store.

Reporting a vulnerability

Security issues are tracked in the repo's SECURITY.md — please report privately there rather than opening a public issue.