Permissions

What permissions control

Permissions express how much autonomy you want Happier to request when an agent uses tools such as file edits or commands. The exact approval and sandbox behavior depends on the selected provider and runtime.

You can set permissions in two places:

• CLI: when starting a session
• App UI: per-session (and as defaults for new sessions)

Happier stores your choice in the session so it stays consistent when you open the same session on another device.

Permission modes

These are the modes you may see in the CLI and/or the app:

• Read-only (read_only): requests a read-only posture and denies write-like actions when Happier is the approver.
• Default (default): uses the provider’s normal behavior.
• Auto (auto): requests automatic tool use according to the provider's closest supported policy.
• YOLO (yolo): skips approvals as much as the provider allows (full speed, least safe).

Not every provider realizes each intent the same way. Auto does not universally mean that writes are confined to the workspace; consult the provider notes below for the behavior of the runtime you use.

Legacy note:

• some older sessions and compatibility paths may still carry plan in permission metadata
• in current Happier builds, Plan is treated as a session mode, not a normal permission choice
• when Happier sees legacy permissionMode=plan, it maps that to Mode = Plan for compatible providers

Session modes

Some providers expose session modes (for example, plan vs build or default vs plan).

Session modes are separate from permissions:

• Permissions control approvals and safety boundaries.
• Session modes control the agent’s operating mode (provider-defined).

Important distinction:

• changing Mode changes the current session
• starting a Plan subagent launches parallel work in the Agents surface

Those are intentionally different features.

For the full user-facing guide, see Session modes.

CLI usage

Start a session with a session mode:

happier claude --agent-mode plan
happier codex --agent-mode plan
happier opencode --agent-mode plan
happier kilo --agent-mode plan

App UI usage

In a session, open the input settings and pick a value from the Mode section when it’s available for the current provider.

If the provider does not support session modes, the Mode control is not shown.

When session modes are available, Happier also supports returning to the provider default mode. In the app this appears as the default/no-override option.

Important: Plan mode does not bypass permissions

Plan mode changes how the provider behaves. It does not mean “auto-approve everything”.

In current Happier builds:

• you can be in Mode = Plan and still receive permission prompts
• your selected permission mode still matters when the provider/runtime asks for approval
• when you exit plan mode, Happier returns the session to the normal working mode for that provider

Exiting plan mode

When a provider asks to exit plan mode, Happier surfaces that as a user-action request, not as a generic permission prompt.

Typical actions are:

• Approve Plan: exit plan mode and continue
• Request changes: stay in plan mode and ask the provider to revise the plan
• provider-specific approval variants such as Accept Edits or Bypass All Permissions

Claude is the clearest example:

• Approve Plan returns the session to Mode: Build
• Approve Plan (Accept Edits) returns to build mode with a safer edit-friendly permission mode
• Approve Plan (Bypass All Permissions) returns to build mode with a YOLO-style permission mode

Those approval variants affect what happens after plan mode ends. They do not mean that plan mode itself bypasses approval prompts.

Resume support

Resume is now a session-level eligibility decision in Happier, not a normal runtime-probing flow.

In practice, Happier decides resumability from:

• the session’s agent/provider
• whether the session has a valid stored provider resume id
• your account/backend settings

For Codex specifically:

• resume depends on the session metadata and the selected backend path
• App Server is the default resumable path in Happier
• if Codex is set to plain mcp, fresh sessions can still run there, but vendor resume is not available on that path
• explicit resume remains fail-closed: Happier errors instead of silently starting a fresh session

For the user-facing workflow, see Resume inactive sessions.

Model selection

Some providers let you choose which model runs your session.

If model selection is available, you can set it from:

• CLI: when starting the session
• App UI: from the input settings inside a session

CLI usage

happier gemini --model gemini-2.5-pro

App UI usage

In a session, open the input settings and pick a model from the Model section.

For ACP providers that advertise supported models, Happier will show the provider’s live list. Some providers also allow entering a custom model id, including Claude Code.

Model apply behavior (what happens after you change it)

Model changes are capability-driven and provider-specific:

• Claude: applies on the next prompt (no session restart required).
• Codex (MCP): model is decided when the MCP session starts; changing model means starting a new MCP session.
• Codex/OpenCode/Kilo/Auggie (ACP): Happier applies model changes live when session/set_model is supported; otherwise it falls back to provider config options when available.
• Devin (ACP): Happier reads the live model choices from Devin's model config option and applies a change with session/set_config_option.
• Gemini (ACP): model changes may require recreating the underlying ACP process; Happier preserves context using replay/history so the session still continues.

For the full guide to engine picking, dynamic/static model lists, custom model ids, model-specific options, and favorite models, see Model and engine selection.

CLI usage

Start a session with a permission mode:

happier codex --permission-mode read-only
happier codex --permission-mode auto
happier claude --permission-mode yolo

For new sessions, prefer:

• --permission-mode ... for approval behavior
• --agent-mode plan when you want to start the session itself in plan mode

Aliases (you can use the words you already know)

The preferred cross-provider input vocabulary is read_only, default, auto, and yolo. The CLI also accepts older Happier spellings and provider-native aliases:

Older clients and stored session metadata can still use the compatible read-only, safe-yolo, acceptEdits, and bypassPermissions wire spellings. Happier normalizes all of these through the same permission-intent parser before applying a provider's own policy. Legacy plan permission metadata is handled as described above.

If you pass an unknown value, Happier prints the supported list and examples.

App UI usage

Change permissions for the current session

In a session, open the permission chip (shield) and pick a mode.

The picker shows a short description of each mode. Provider/runtime behavior can still narrow or reinterpret the selected intent, as described in the provider notes.

Action approvals are separate

Action approvals are configured independently from permission modes.

Use Settings → Actions when you want to choose, per action and per surface, whether Happier should:

• make the action available at all
• route the action through an approval request before it executes

That same approval model applies across the main action surfaces, including:

• the session agent surface
• the CLI surface
• the external MCP surface
• voice surfaces

For the broader model, see Happier tools & actions and Inbox and approvals.

Set defaults for new sessions

Go to Settings → Session → Permissions and set your default permission mode per backend choice.

The defaults screen is designed around two separate concerns:

• Default permissions for each enabled backend choice
• Apply permission changes for running sessions

That split matters because those settings solve different problems.

Dedicated Permissions screen

In the app, the Permissions screen is the central place for session-permission defaults.

Open:

1. Settings
2. Session
3. Permissions

Default permissions

The Default permissions section shows one row per enabled backend choice.

Important details:

• the list is dynamic
• it is generated from the resolved backend catalog
• it is not hardcoded to specific providers in the UI

This means:

• if you enable a new backend, it can appear automatically
• if a backend is unavailable in your current account/build, it should not appear
• configured Custom ACP backends can appear here alongside built-in providers

Apply permission changes

The Apply permission changes section is a separate dropdown.

It controls when a permission change should take effect:

• Immediate: publish the new permission mode to the session right away
• Next prompt: arm the change locally and publish it when you send the next message

This is useful because some users want a running agent to react immediately, while others want the next turn to be the first one that uses the new permission mode.

Prompt surface

The same screen also lets you choose where permission requests should appear:

• in the composer, or
• in the transcript

That setting changes the UI surface for approvals. It does not change the underlying permission decision.

Remembering approvals for the current session

When Happier shows a permission prompt, some providers can also offer scoped “don’t ask again” choices.

Examples:

• don’t ask again for this tool
• don’t ask again for this command

These choices update the current session’s allowlist so later matching requests do not prompt again in that same session.

Important details:

• this is session-scoped, not a permanent global policy
• command-scoped approvals are narrower than tool-scoped approvals
• if the provider/runtime does not support a matching allowlist update, Happier falls back to normal prompting

Push notifications for permission and user-action requests

When push notifications are enabled for the account, Happier can also notify you when a session is blocked on either:

• a permission request, or
• a user-action request such as AskUserQuestion or Exit Plan Mode

Current mobile behavior:

• the notification can show the requested tool or request type
• it may include a short detail hint, such as a file hint or command name
• it can expose:
  • Allow / Deny for permission requests
  • Answer for user-action requests

Pressing Allow or Deny opens the app, sends the response when the target server is already active or already saved on the device, and then returns you to the session.

Pressing Answer opens the app on the exact session so you can answer in context.

If the notification targets a server that is not already trusted on the device, Happier routes you through the safer add/switch flow instead of auto-approving on an unknown server.

Transcript-storage defaults

When your current server/build supports transcript-storage choices, the Permissions screen can also show the default storage mode for new sessions per backend choice.

That lives here because it affects the default safety / persistence posture of new sessions.

When does a change apply?

In Settings → Session, you can control when a permission change takes effect:

• Immediate: publish the new permission mode to the session right away (best when you want the running agent to react without sending a new message).
• Next prompt: apply the new mode to the next message you send, and publish it after that message is committed (best when you want the change to “arm” for the next request without touching the current running turn).

If you select Next prompt and then don’t send a message, the change stays local to your device until you send one.

What the dropdown rows show

In current app builds, permission dropdown rows show the current selection directly in the row itself.

That means you can usually see:

• the selected mode label on the right, and
• the explanation for the selected option as the row subtitle

without reopening the dropdown.

Provider notes (what to expect)

Codex (App Server default, ACP optional, MCP for fresh sessions)

Codex can run via different backends:

• App Server: the default backend in Happier and the normal resume path when the session has valid Codex resume metadata
• ACP: still available when you explicitly switch Codex to ACP mode; resume can also work there
• MCP: still usable for normal fresh sessions, but plain MCP is not a vendor-resume path in current Happier builds

In Happier, permissions remain the primary control for Codex. Happier maps your selected permission intent to the closest backend-native policy for the active Codex backend.

Model IDs can also vary by Codex build and account. If model selection isn’t shown in the app for your Codex session, you can still set it via the CLI (when supported by your installed Codex backend).

The selected intent is portable, while its realization depends on the active Codex backend's approval and sandbox policies.

Devin (experimental)

Devin sessions and execution runs use the installed, machine-authenticated Devin CLI through devin acp. Happier maps explicit permission choices to Devin's advertised modes:

• Default sends no permission override, so Devin keeps the user's configured permission behavior.
• Read only uses ask.
• Auto (the canonical safe-yolo intent) uses smart.
• YOLO uses bypass.
• Plan uses plan.

Happier can resume Devin sessions and switch among the live model choices reported by the CLI. Happier delivers the built-in Happier tools and your selected MCP servers through a protected, process-scoped Devin MCP configuration because Devin currently ignores MCP servers supplied in the standard ACP session request and exposes no direct per-process MCP flag. Execution runs use this same native launch path: Happier lazily resolves one run-scoped set of MCP servers and supplies it when the Devin process starts. This MCP setup is independent of Default permission behavior; leaving permissions at Default still sends no permission override. Your existing user-level Devin MCP servers are merged into the temporary configuration under the platform's native config root (XDG_CONFIG_HOME on macOS/Linux or APPDATA on Windows), while other Devin and Cognition config entries are linked into it. If linking fails, Happier stops the launch instead of copying provider state into a stale snapshot. Happier removes the temporary root when the agent process ends and does not modify the MCP configuration in your home directory or project. Devin still loads non-colliding project and project-local MCP servers normally; if one shadows a session-selected server name, Happier stops before launch with an actionable error instead of silently running the project definition.

Claude

Claude supports both:

• normal Happier permission modes, and
• a provider-specific Mode = Plan

While Claude is in plan mode:

• Claude can still ask for permissions
• Happier still surfaces permission prompts normally
• Exit Plan Mode is surfaced as a user-action request with plan-specific approval choices

Pi

Pi uses an explicit tool allowlist for Read-only (and compatible legacy Plan permission metadata). For Auto, Default, and YOLO, Happier does not pass Pi's --tools option, so Pi retains its full native catalog, including its platform shell and installed extension/custom tools such as subagents. Auto is therefore not a workspace-confinement boundary for Pi.

Remembering a shell command

When you allow a shell command and ask Happier to remember it, the grant is narrower than it looks — deliberately, because "remember git" should not become "run anything that starts with git".

An exact match on the whole command always wins, including a chained one you approved as a unit. Otherwise Happier parses the command and applies three rules:

• Unquoted redirection is refused. An unquoted < or > anywhere in the command means no remembered grant applies.
• Every segment must match on its own. A command containing control operators is allowed only if each top-level segment is separately allowed. This is what stops a git:* grant from also permitting git status && rm -rf ….
• Unparseable input fails closed. An unterminated quote or a trailing escape is refused rather than guessed at.

A refused command is not blocked outright — you are simply asked again, rather than the grant being stretched to cover something you did not approve.

Related

• Custom ACP
• Model and engine selection
• Profiles
• Session modes
• Session settings