100xprompt changes your files and runs real commands. That power is only useful if you stay in control of it. So before it does anything consequential - editing a file, writing a new one, running a shell command, reaching outside your project - it checks a permission decision. Some actions it just does, some it asks you about, and some it refuses outright, all according to rules you set. This page covers the three decisions (allow / ask / deny), the permission modes you switch between mid-session, and the config rules that pre-approve the safe things and lock down the risky ones.

​
How the permission gate works

Every sensitive action flows through the same gate. 100xprompt looks up a decision for that specific action - factoring in your config rules, the current permission mode, and anything you’ve already approved - then proceeds, pauses to ask you, or stops.
Read-only actions - reading files, searching, listing directories - are safe by default and don’t interrupt you. The gate is there for the actions that can actually change something.

​
Know the three decisions

Every rule resolves to one of three actions.
DecisionWhat happensUse it for
allowThe action runs immediately, no prompt.Trusted, reversible, or read-only operations.
ask100xprompt pauses and asks you to approve before continuing.The default for anything that changes state.
denyThe action is refused. The model is told it can’t, and continues without it.Commands or paths you never want touched.
When 100xprompt asks, you get three responses: Allow once (this call only), Allow always (remember this kind of action for the rest of the session so you’re not asked again), or Reject (refuse - optionally with feedback the model uses to adjust course).

​
Switch permission modes mid-session

Suppose you want the whole session to be more cautious - or more autonomous - without editing any config. Permission modes are a session-wide posture you flip on the fly. A mode overlays your rules for the rest of the session. Cycle through them with the Cycle permission mode command in the terminal app, or set one explicitly.
ModePostureWhen to use it
DefaultYour configured rules apply as-is. Sensitive actions ask; safe ones proceed.Everyday work. The balanced starting point.
Accept editsFile edits and new files are auto-approved. Running commands still asks.A focused editing session where you trust the plan and don’t want to confirm every file change.
Plan (read-only)Investigation only. Every state-changing action - edits, commands, spawning sub-agents - is blocked.Exploring a codebase or having 100xprompt draft a plan before it touches anything.
AutoA classifier judges each would-be prompt: clearly safe actions are allowed, risky ones still ask.Longer autonomous runs where you want fewer interruptions but still a stop on anything risky.
BypassEverything is auto-allowed - no prompts at all.Throwaway sandboxes and disposable environments only. See the warning below.
Bypass mode removes every safety prompt. 100xprompt will edit files and run commands - including destructive ones - without asking. Never use it on a machine with data you care about, on a shared or production system, or against untrusted code. It is deliberately kept out of the normal mode-cycle so you can never land in it by accident; you have to opt in explicitly. Prefer Auto if you want fewer prompts without giving up the guardrails.
Plan mode is the safest way to start on an unfamiliar codebase. Let 100xprompt read, search, and propose a full plan while it’s physically unable to change anything, then switch to Default or Accept edits once you’re happy with the approach.
Two important properties of modes:
  • The Auto classifier never overrides a deny. A mode can upgrade an ask to an allow (Accept edits) or turn things into denies (Plan), and the Auto classifier only ever promotes an ask to an allow - it can never relax a rule you set to deny. The one exception is Bypass, which by design allows everything (see the warning above); reach for Auto, not Bypass, when you want a deny to keep holding.
  • Modes are session-level. Switching modes changes the current session’s posture and doesn’t rewrite your saved config.

​
Configure durable rules in config

Modes are temporary. For durable control, set rules in your 100xprompt.json. Rules live under a permission key, addressed by capability (what kind of action) with an allow / ask / deny decision. Commands additionally support pattern matching, so you can be precise about which ones are pre-approved.

​
Capabilities you can gate

CapabilityCovers
editEditing existing files and writing new ones.
bashRunning shell commands.
readReading file contents.
webfetchFetching a URL’s contents.
websearchSearching the web.
external_directoryActing on paths outside your project directory.
taskSpawning sub-agents to do work in parallel.
A bare string is shorthand for “apply this decision to everything.” "permission": "ask" makes 100xprompt ask before every sensitive action; "deny" locks it all down.

​
A balanced starting point

Auto-approve reads and searches, ask before edits, and ask before running commands:
100xprompt.json
{
  "permission": {
    "read": "allow",
    "edit": "ask",
    "bash": "ask"
  }
}

​
Match commands by pattern

The bash capability accepts an object that maps command patterns to decisions. Patterns support * wildcards. Rules are evaluated in the order you write them and the last matching rule wins - so put your broad baseline first and let the narrower exceptions below it override.
100xprompt.json
{
  "permission": {
    "bash": {
      "*": "ask",
      "git status": "allow",
      "git diff *": "allow",
      "npm run test*": "allow",
      "npm run *": "ask",
      "git push *": "ask",
      "rm -rf *": "deny",
      "curl *": "deny"
    }
  }
}
In this example: 100xprompt runs git status, git diff, and your test script without interrupting you; it still asks before other npm run scripts and before pushing; and it will never run rm -rf … or curl …, regardless of context. Because the last matching rule wins, npm run test* (listed after npm run *) is what decides a test command.
When you approve a command with Allow always, 100xprompt remembers a sensible prefix for it - so approving npm run test once won’t force you to re-approve every future test run in that session. Encode the patterns you always trust directly in config so they’re allowed from the very first run.

​
Scope edits and external access by path

edit and external_directory also accept path patterns, so you can allow edits in some areas and forbid them in others. The same order rule applies - write the broad decision first and the exceptions after it:
100xprompt.json
{
  "permission": {
    "edit": {
      "*": "ask",
      "src/**": "allow",
      "**/*.env": "deny",
      "infra/**": "deny"
    }
  }
}
Here edits under src/ are automatic, environment files and infrastructure are off-limits, and everything else prompts. **/*.env sits after src/**, so a file like src/config.env is denied even though src/ is otherwise allowed.

​
Rely on the always-on guardrails

Some protections hold independent of your rules and mode:
Any command or action that would reach outside your project directory is treated as a distinct, higher-trust decision. Even in Accept-edits mode, stepping outside the project prompts you.
Reading, searching, and listing are safe by default and never interrupt you - so the prompts you do see are always about actions that can actually change something.
The Auto classifier only ever promotes an ask to an allow - it can never relax a rule you set to deny. Once you’ve forbidden a pattern, no autonomous run in Auto can talk 100xprompt into it. (Bypass is the deliberate exception: it turns off every check, which is why it’s kept out of the normal cycle.)
When you reject an action, 100xprompt doesn’t crash or silently retry - it’s told the action was declined (and your feedback, if you gave any) and adjusts its plan accordingly.
“Allow always” applies for the current session, not forever. Start a fresh session and the higher-trust posture resets to your saved config.
Config rules and modes govern what 100xprompt does on your behalf - they are not a security sandbox. When you run 100xprompt against untrusted code or with autonomous settings, run it in an isolated environment. For organization-wide enforcement, see the enterprise security guide.

​
Set up permissions end to end

1

Set a sane baseline in config

Allow reads and searches, ask before edits and commands, and deny the handful of patterns you never want touched (rm -rf *, secrets, infra).
2

Pre-approve the commands you always trust

Add your test, lint, build, and git status/git diff patterns as allow so routine loops run uninterrupted.
3

Start new work in Plan mode

Let 100xprompt investigate and propose a plan while it can’t change anything, then switch to Default or Accept edits to execute.
4

Reach for Auto, not Bypass

For long autonomous runs, use Auto so safe actions flow but risky ones still stop for you. Save Bypass for disposable sandboxes.

Settings

Where 100xprompt.json lives and every other key you can configure.

Running Commands

How 100xprompt runs tests, builds, and git - the actions permissions govern.

Enterprise Security

Org-wide policy, enforcement, and isolation for teams.