Permissions

Permission settings control whether fx can change files, run commands, and access paths outside your workspace.

Modes

Auto mode

auto is the default permission mode. It runs routine development actions directly and reviews other actions before running them.

Runs directly

• Read files and search code or the web
• Create or edit ordinary project files
• Run recognized project commands, including git status, local dependency installs, tests, builds, and development servers

Reviews first

• Run unrecognized or dynamic shell commands
• Overwrite files outside the workspace
• Change sensitive configuration
• Call an MCP server tool

For reviewed actions, fx sends the exact action to a model that checks for prompt injection or malicious behavior. If the model finds no problem, fx runs the action. If the model flags a problem or cannot finish the review, fx holds the action and tells the agent why.

The review model depends on your provider:

To choose another AI Gateway reviewer, add review_model to ~/.fx/settings.json:

{
  "review_model": "typesafeai/jev"
}

FX_REVIEW_MODEL overrides it for one process. The setting accepts an AI Gateway chat model ID or typesafeai/jev. Jev uses AI Gateway unless TYPESAFE_API_KEY is set, in which case fx calls TypeSafe directly. Codex and Grok use their fixed reviewers. Custom connections use their own reviewer_model.

Each model review uses tokens and can add to your usage and costs. Actions allowed or denied by your rules do not need a model review.

To change how fx handles a matching action, add a persistent rule that allows it, denies it, or asks for your approval.

Change the mode

In the interactive shell:

/permissions reset switches back to ask and clears the grants collected in this session.

From your terminal, inspect the effective mode and rules:

Use fx ask --full-access <prompt> to disable fx permission checks for one request.

You can also set the mode with permission_mode in ~/.fx/settings.json or the FX_PERMISSION_MODE process override. See Configuration.

When fx asks

In ask mode, unresolved sensitive calls open an approval prompt with three choices:

Persistent rules

Permission rules are stored in ~/.fx/settings.json, either globally or under the current workspace profile. Project .fx.json files cannot define them.

{
  "permission": {
    "*": "ask",
    "bash": {
      "git *": "allow",
      "git push *": "deny"
    },
    "edit": {
      "*": "deny",
      "docs/*": "allow"
    }
  }
}

Rules use wildcard matching. The last matching rule wins, and workspace rules take precedence over user-global rules.

Put broad rules before specific exceptions. In the example above, edits are denied by default and then allowed under docs/.

Use /allowlist in the interactive shell to inspect or change rules. Choose local for the current project or user for rules that apply across projects.

Rules saved with a conversation

You can remember an exact allow or deny decision for a saved conversation without granting it to the whole project. In an active saved session:

/permissions remember allow shell {"action":"run","command":"git status"}

fx shows the prepared action for confirmation. Confirming saves the rule; it does not run the command. A different command is a different action.

Use /permissions to inspect the saved rules and their IDs, then remove one with /permissions revoke <rule-id>. Revocation also asks for confirmation. These rules survive resuming the conversation. A configured deny still takes precedence over a saved-session allow.

Session grants

Choosing "Yes, and don't ask again" creates a live session grant. It is not written to settings and is not restored by fx resume.

If a call is denied or reviewed when you did not expect it, see Troubleshooting.