Permissions and Safety

Docs RightNow Agent Permissions and Safety Updated 2026-10-17

View as Markdown

Release status

RightNow Agent, the terminal coding agent, is paused. Its guides stay online as reference.

How RightNow Agent decides whether a tool call runs, and where that decision stops protecting you.

Build from source

The reference below describes a build from the pinned agent source.

Permission modes

Warning: Always-approve is not a sandbox

--always-approve, --yolo, and --dangerously-skip-permissions auto-approve tool execution. They do not isolate the process and should not be used for untrusted work.

Auto mode

PowerShell

rightnow --permission-mode auto

Always approve one task

Text

rightnow --always-approve -p "Run the test suite"

Compatibility name

Text

rightnow --permission-mode bypassPermissions

CLI / compatibility name	Behavior
default	The ordinary ask mode. Runs read-only tools and built-in read-only shell commands without prompting, then asks for other actions.
acceptEdits	File edits run without a prompt; everything else follows the permission pipeline.
plan	Accepted for Claude-compatible settings. Use plan mode for gated planning.
auto	Runs work that passes the safety check. Other calls are blocked or escalated.
dontAsk	Runs only pre-approved tools and built-in read-only handling. Other calls are denied instead of prompting.
bypassPermissions	Always-approve. In native TOML, set `permission_mode = "always-approve"` under the `[ui]` table. Tool calls generally run, but deny rules, hooks, and some shell ask rules still apply.

Native [ui] permission_mode values are default, ask, auto, and always-approve. A CLI flag overrides config for that process.
In the TUI, switch with Shift+Tab or Ctrl+O, /always-approve, /auto, or /settings.
Always-approve and auto are mutually exclusive; always-approve wins when both are requested.
Administrators lock always-approve off with [ui] disable_bypass_permissions_mode = true in requirements.toml.

An edit prompt at full width, with the default cursor on the first choice. Legacy ConHost draws the selected mark differently.

rightnow: review an edit

Allow Edit to <file-path>?
1 (●) Yes, and don't ask again for anything (always-approve mode)
2 (○) Yes, allow all edits during this session
3 (○) Yes
4 (○) No, reject (type to add feedback)
1/4:select  │  Tab:next option  │  Ctrl+o:always-approve  │  Ctrl+c:cancel  │  Esc:scrollback

How authorization is evaluated

TOML

[permission]
deny = ["Bash(Remove-Item *)", "MCPTool(sales__delete_*)"]
ask = ["Edit"]
allow = ["Bash(git *)", "Read", "Grep"]

PreToolUse hooks may deny or rewrite the request.
Permission rules are merged and evaluated by severity: deny, then ask, then allow.
Remembered grants may satisfy an approval for the current project.
Built-in read-only approvals cover read tools and a fixed set of read-only shell commands.
Approval handling depends on the active mode. Always-approve is checked before session grants; auto mode uses built-in checks and a classifier before ordinary read-only approvals. Policy denies and hook denials still apply.

Any matching deny rule wins. If no deny matches, an ask rule wins over allow; rule order in a file does not matter.

Deny and ask rules check every segment of a chained shell command, but an allow rule matches the whole string, so Bash(git *) also approves git status && rm -rf /. Pair narrow allow rules with deny rules.

Where rules come from

Source	Scope
--allow / --deny	Repeatable CLI rules for the current process.
<RIGHTNOW_HOME>/config.toml	User rules for all projects.
.rightnow/config.toml	Rules from the repository root through the working directory.
.claude/settings.json and .claude/settings.local.json	Compatible global, project, and personal project rules.
managed configuration	Organization rules and requirements.

Rules are read when a session starts; changes apply to the next session.

Sandbox boundaries

Sandbox mode resolves from a managed requirement, then --sandbox, then RIGHTNOW_SANDBOX, then [sandbox] profile, and is otherwise off. A resumed session keeps its saved profile.

Warning: Windows boundary

These settings do not provide kernel-enforced isolation on the Windows product path. Permission prompts are application decisions, not filesystem or network isolation; use an external containment boundary when stronger isolation is required.

On macOS and Linux, a selected profile can add operating-system enforcement; child-process network blocking applies only on Linux. Compare profiles and failure behavior on the Sandbox page.

Shell environment policy

TOML

[shell_environment_policy]
inherit = "core"
ignore_default_excludes = false
exclude = ["ACME_*", "CI_*"]
include_only = ["PATH", "HOME", "MY_FLAG"]
set = { MY_FLAG = "1" }

By default, tool commands inherit ordinary environment variables and filter names matching *KEY*, *SECRET*, or *TOKEN*. Matching is case-insensitive, and an explicit shell environment policy can change this independently of sandbox isolation.

The policy applies these steps in order.

Step	Values and effect
`inherit`	`all` starts with inherited variables, `core` with core platform variables, and `none` with an empty environment.
Default filter	When `ignore_default_excludes` is `false`, drop `KEY`, `SECRET`, and `TOKEN` matches.
`exclude`	Drop matching variable names.
`set`	Set the supplied variable values.
`include_only`	If nonempty, retain only matching variable names.

Treat inputs as untrusted

Repository text, command output, fetched pages, MCP output, hooks, and migrated rules can all influence an agent session.

Before approval, review commands, paths, destinations, URLs, headers, and environment values. Keep credentials in the environment or an approved secret mechanism, never in committed configuration or shared logs.

Next task

Choose a sandbox profile for the operating system and paths you use.