Approval mode and CLI flags

The setting that decides whether unattended turns work at all — per-job approval flags for each CLI, and why programmatic flags are refused.

This is the setting that decides whether unattended turns work at all. It is worth reading before you set up your first job.

The problem

A turn uses the CLI launch flags, which are global. If your interactive Claude is set to a cautious approval mode — which is exactly what you want when you are sitting in front of the screen — a turn will stop at the first confirmation, wait, and eventually count as a failure.

Nothing is broken. The agent is doing what your settings told it to do, with nobody there to answer.

The fix: per-job approval flags

The approval flags for this job field — in the Advanced section of the job editor — overrides that setting for that job only. Your interactive setup stays as careful as it was.

Format is key=value:

CLI Example
claude permissionMode=bypassPermissions
codex askForApproval=never
antigravity mode=accept-edits
vibe agent=auto-approve
kimi auto=true
opencode dangerous=true

Claude is the only CLI whose confirmation box OFM can read. Its confirmations can be auto-approved by the rules engine even without an override.

For every other CLI, setting the job’s auto-approval is the prerequisite for an unattended turn. Without it, the turn will sit on a confirmation until it times out.

Programmatic flags are refused

Flags that switch a CLI into programmatic mode are rejected:

-p   --print   exec   --output-format

Those paths are billed against the metered programmatic pool rather than your subscription. A recurring job — which by definition runs while you are not watching — is precisely where an accidental API meter would do the most damage before anyone noticed.

So the door is closed at the flag level, not left to discipline. See subscription vs API for why OFM draws the line where it does.

Weigh it honestly

Auto-approval means an agent applies changes to your working tree with nobody reviewing each step. That is the point of unattended work, and it is also its risk.

Two things reduce it, and neither is OFM’s doing:

  • Start with a job that reads and reports rather than one that writes.
  • Keep the project under version control, so you can read the diff afterwards.

See quota, limits and safety for what a job can and cannot undo.

Frequently asked

Why does my recurring job stop on the first confirmation?
It is inheriting your global CLI launch flags, which are probably set to a cautious approval mode. Set the per-job approval flags in the editor's Advanced section to override them for that job only.
Can I make a recurring job run headless to avoid confirmations?
No. Flags that switch a CLI into programmatic mode are rejected — that path is billed at API rates, and OFM will not open it.

Last updated