Helios / User guide / Permissions and approvals

Permissions and approvals

Choose Helios execution permissions, respond to tool approvals and questions, and understand each provider's limits.

Check the Execution controls

The conversation toolbar’s Execution control combines workflow, reasoning and permissions. Defaults for new chats live in Settings; the active conversation can have its own choices.

Supported reasoning levels and workflows depend on the provider, installed CLI and selected model. Helios uses the capabilities the integration reports rather than giving every model the same controls.

A conversation rooted at exactly $HOME is forced to read-only. Choose a real project subfolder before starting an editing task.

Understand permission modes

The following is a practical overview. Read the provider’s own policy before using broad access; the same label does not create identical isolation across providers.

Mode	What to expect
Ask	Tools requiring approval prompt through the provider’s supported approval flow. Codex uses a workspace-write sandbox with network disabled.
Accept edits	Supported file edits can proceed without repeated approval. Commands or access beyond the workspace can still require approval.
Auto	Provider-dependent automation. For Codex and OpenRouter it follows their Accept edits mapping.
Plan / Read only	Investigation with restricted writes, according to the provider’s native mode. Supported Codex Plan workflow forces read-only permissions.
Bypass	Broad access without approval prompts. Do not treat it as a sandbox.
Never ask	Highly provider-specific. In Kimi it maps to native YOLO, just as Bypass does; it must not be treated as a restricted refusal mode.

Check provider differences

Claude: uses the CLI’s native permissions, approvals and Plan review. Session rules apply to that running conversation process.
Codex: combines its App Server approval policy with a native sandbox. Network access differs by mode; a sandboxed network failure can need escalation or be refused.
Gemini: Antigravity offers Sandboxed, Accept edits, Bypass and Read only. Its headless integration cannot show or answer interactive approval requests. Sandboxed modes can still allow workspace writes.
Muse: uses MSP permission mappings. Its sandbox posture is established when the provider process starts.
Kimi: uses ACP/native configuration. Both Helios Never ask and Bypass map to Kimi’s YOLO setting.
OpenRouter: Helios controls its own tool loop. Reads, edits, commands and access outside the project are governed by its local mode mapping.

For exact native mappings and credential handling, consult the security reference and provider setup guide.

Respond to approvals and questions

An approval shows the tool, requested operation and available provider choices. Read the command or diff before allowing it. Depending on the integration, you can allow once, allow a rule for the running session, deny, or send explanatory feedback.

Claude’s Allow for this session remembers the rule until that agent process exits. Allow and auto-accept edits, when offered, also changes that conversation to Accept edits.

Question dialogs preserve the provider’s choices and a typed answer where supported. A question from a subagent identifies that agent. If the provider withdraws a question or the turn ends, its old answer dialog is no longer valid.

Approve plans and stop work

Claude Plan mode can submit a plan for review. You can approve it, approve with edits auto-accepted, or send feedback to keep planning. Approving changes the conversation out of Plan mode.

Esc or Ctrl+. stops the current turn. Ctrl+Shift+. is the emergency stop across sessions and the shared Codex transport. Cancellation is a request to the running integration; check the resulting state before assuming all external work has ended.