Docs/Tools & Features/Permissions & Security

Permissions & Security

Dynamo's permission system balances safety with speed.

Permission Levels

LevelBehaviorExamples
SafeAuto-execute, no promptread_file, list_files, search_files, git_status, memory_list
WritePrompts once per tool, per model (persists for the session)write_file, edit_file, git_commit, web_fetch
DangerousPrompts. "Allow all" is never offered here — but see the note below on grants taken at write level.run_command (every command — ls as much as rm), move_file, rename_file, delete_file, checkpoint_restore, job_kill, plus git_push to main/master or with a force flag
BlockedRejected immediately, not skippable by Auto ModeShell strings matching sudo, or command/process substitution

checkpoint_restore and job_kill prompt *every* time, including in Auto Mode; so do protected-file writes (see below). The Blocked row matches run_command argument strings — the structured git_push tool escalates to dangerous instead of being refused.

One force-push spelling is refused as a shell string too — the literal git push --force …main. Only that spelling: git push -f origin main, or --force written after the branch, aren't matched and land in the dangerous tier, which Auto Mode approves. It's a typo-catcher rather than a guardrail, and the structured git_push tool escalates rather than being refused.

Grants are stored per tool + model, not per level. "Allow all" is never offered on a dangerous call, so you can't batch-approve one directly. But the two tools whose level is computed per call — git_push and git_lfs_unlock — can hold a grant taken at write level, and that grant covers the same tool's dangerous shape later in the session. Allowing all git_push on a feature-branch push therefore also covers a later push to main or a force-push, and grants survive /resume. That's the reason to withhold the grant on those two rather than the reason it's safe to give.

Approval Menu

When a tool requires approval, you see:

  • ●Human-readable description of what the tool will do
  • ●Expandable raw call details (press → to expand)
  • ●Diff view for file edits with line numbers and colored +/- lines
  • ●Allow / Allow all / Deny options — Allow all is not offered when the call in front of you is dangerous, so a stored grant is write-level consent by construction

"Allow all" is scoped per-tool per-model. Allowing write_file for Claude doesn't auto-allow it for GPT. Switching models and switching back preserves your approvals. Approvals persist across session resume.

Auto Mode

bash
dynamo -y
dynamo --auto

Auto Mode approves the whole dangerous tier, not just routine writes — every run_command sits in that tier, ls as much as rm, because Dynamo doesn't rank shell commands against each other. Turning it on is one trust decision about the shell.

Three things still stop in Auto Mode:

  • ●Blocked commands — refused outright, never run.
  • ●Protected-file writes — still ask first.
  • ●`checkpoint_restore` and `job_kill` — always prompt.

Per-Model Permissions

Permissions are tracked as a per-model map. Each model has its own set of "Allow all" grants — granting write_file for Claude doesn't auto-grant it for GPT, so a more powerful model never inherits a weaker one's approvals. Switching models doesn't wipe any model's grants: switch away and back and your previous approvals are still there. Grants also persist across session resume.

Sandbox Mode

Controls filesystem access for all tools including shell commands.

Moderead_filewrite/editlist/searchrun_command
projectproject onlyproject onlyproject onlyblocks external paths
full (default)project onlyproject onlyanywherepermission gated
unrestrictedanywhereanywhereanywherepermission gated

Set via CLI (--sandbox project), config (ai.sandbox: project), or at runtime (/sandbox).

In project mode, shell commands that reference absolute paths outside the project are blocked. sudo is always blocked regardless of sandbox mode.

Checkpoints

Dynamo snapshots your work before risky operations so you can roll back.

  • ●Auto-snapshot — taken once per prompt, before the first write_file/edit_file and before a destructive run_command
  • ●Rollback modes — code (restore files only), conversation (rewind history only), or both
  • ●Retention — checkpoints are stored under your config dir, per project, and pruned after 30 days
  • ●Manage — run /checkpoint for an interactive overlay to list, create, or restore. The model can also call checkpoint_list / checkpoint_create / checkpoint_restore.

Security Hardening

  • ●Command injection detection — command substitution ($(), backticks), parameter expansion (${}), and process substitution (<(…), >(…)) are always blocked
  • ●Compound command splitting — cmd1 && cmd2 — each part checked independently
  • ●Protected files — writes to .env, .env.*, .git/config, .git/hooks/*, .ssh/*, .bashrc, credentials.json, *.pem, *.key and other shell/credential files always require explicit approval, even in Auto Mode. Most patterns are anchored at the project root, so a nested apps/api/.env is not covered (*.pem / *.key match by suffix at any depth).
  • ●Secret scanning — secrets are blocked outright in memory_save, warned on write_file, and noted on read_file
Terminal SupportUnity Integration