Feature request: Claude seats can't launch in auto permission mode — hard-coded --permission-mode acceptEdits overrides settings defaultMode #33

Summary

Claude seats can only launch in one of two postures: the floor, --permission-mode acceptEdits, or full_bypass (--dangerously-skip-permissions). There is no way to launch a Claude seat in Claude Code's auto permission mode, where a classifier approves or blocks each tool call. For autonomous pool seats, that middle option is the useful one.

Setting permissions.defaultMode: "auto" in the seat's settings doesn't help. OpenRig always passes --permission-mode acceptEdits on the command line, and the CLI flag overrides the settings value. The only way to get auto today is pressing Shift+Tab in each seat's TUI, and that's lost on every relaunch or resume.

Environment

• OpenRig CLI/daemon 0.5.14
• Claude Code 2.1.281 (--permission-mode choices include auto)
• Ubuntu 26.04, a rig of 9 unattended Claude seats (1 orchestrator, 5 devs, 3 QA)

Repro (flag overrides settings)

# What OpenRig launches: the flag wins over settings
claude --permission-mode acceptEdits --settings '{"permissions":{"defaultMode":"auto"}}'
# status bar: ⏵⏵ accept edits on

# Same settings without the flag
claude --settings '{"permissions":{"defaultMode":"auto"}}'
# status bar: ⏵⏵ auto mode on

Details (from the shipped dist/)

adapters/yolo-mode.js:

export function claudePostureFlag(env = process.env, resolvedPosture) {
    return yoloEnabled(env, resolvedPosture) ? "--dangerously-skip-permissions" : "--permission-mode acceptEdits";
}

It is used on both the fresh-launch path (claude-code-adapter.js) and the resume path (claude-resume.js), so no settings, policy or profile can pick a different Claude mode.

Separately, the applying-a-permission-policy skill says a settings.json without defaultMode: "acceptEdits" "strips the floor". Given the repro above, the launch flag sets the floor regardless of what the file says.

Impact

In acceptEdits, every Bash command outside the allowlist raises a prompt, and on an unattended seat nobody answers it, so the seat stalls. It gets much worse when Claude's sandbox can't start. On Ubuntu 24.04+, AppArmor's bwrap-userns-restrict profile denies sys_admin inside bwrap, so every sandboxed command fails. It is then retried unsandboxed, and each retry needs approval. In our rig, 5 of 9 seats sat on permission prompts within minutes of rig up. The seats we had switched to auto by hand ran a full issue → implement → QA → MR cycle with no human input.

full_bypass does fix the stalling, but it removes all checks. auto keeps the classifier as a guard, which is the posture we actually want for these seats.

Requests

1. Add a Claude launch posture that maps to --permission-mode auto, selectable per seat (e.g. permission_policy: builtin:auto or a launch_posture: auto resolved posture) and globally (e.g. OPENRIG_CLAUDE_PERMISSION_MODE=auto). Apply it on the fresh, resume and fork paths, the same way full_bypass is applied.
2. Alternatively, when a seat's resolved settings set permissions.defaultMode, pass that value as --permission-mode (or omit the flag) instead of hard-coding acceptEdits.
3. Update the applying-a-permission-policy skill: it should say the launch flag sets the Claude mode and defaultMode in settings.json has no effect under OpenRig.

Current workaround

After every rig up or resume, press Shift+Tab in each Claude seat's terminal until the status bar reads auto mode on.