v0.8.67: Separate work mode from approval policy before any Auto loop

[Hmbown]

Summary

The mode/permission model carries four overlapping knobs in EffectiveModePolicy (crates/tui/src/tui/app.rs:1110-1119): allow_shell, approval_mode, trust_mode, auto_approve. Three of them co-vary in every mode, which is the structural source of the "UI says one mode but a different flag decides" bugs (#3733 Auto, #3735 YOLO-publish).

Current state (3 surviving modes after Auto deferral)

Mode	allow_shell	approval_mode	trust_mode	auto_approve
Plan	false	Suggest	false	false
Agent	prefs	prefs	prefs	false
YOLO	true	Bypass	true	true

YOLO sets three flags that all mean "approve everything."

What each knob really does

• approval_mode (approval.rs:41-51): Suggest/Auto/Bypass/Never — the one genuinely meaningful control.
• trust_mode (bool): enables sandbox workspace writes, skips the untrusted-workspace safety hold, and contributes to auto-approval (auto_approve || trust_mode, runtime_threads.rs:3296).
• auto_approve (bool): skip prompts; fully covered by approval_mode == Bypass.

Proposal — collapse 4 → 2

1. approval_mode stays the single approve/ask/bypass/never control. Derive auto-approval from approval_mode == Bypass and delete auto_approve (remove the separate flag at app.rs:1117-1118 and its mirrors; replace auto_approve || trust_mode with approval_mode == Bypass || trust_mode).
2. trust_mode keeps its one distinct job — workspace-write capability + untrusted-workspace handling — and stops doubling as an approval flag.
3. allow_shell can likely be derived too (Plan = no shell; Agent/YOLO = shell), but keep for now if prefs need per-user shell toggle in Agent.

Why

Removing auto_approve as an independent flag eliminates the layer split that lets safety_floor's HoldForReview get silently bypassed (#3735) and that makes mode label and behavior disagree (#3733). One control = one source of truth.

Verification

• Existing mode/approval tests still pass after deriving auto-approval from approval_mode.
• Add: YOLO still auto-approves ordinary tools; publish-like HoldForReview still prompts (ties to YOLO mode silently approves publish actions (cargo publish / git push --tags), defeating safety_floor durable-review #3735).

Refs #3733, #3735, #3568.

[Hmbown]

v0.8.66 scope correction: no fake Auto mode

Hunter's product direction: do not treat Auto as a fourth surface-level mode. The current immediate release problem is that CodeWhale mixes work intent, shell access, trust, and approval bypass into overlapping flags. That is why the UI can say one thing while a different flag decides tool/MCP prompting.

Research signal checked on 2026-06-30:

• Codex's current auto-review framing is still an approval/sandbox boundary: the agent can request escalation, the reviewer decides within a policy, and risky work stays separated from normal execution.
• Codex's iterative repair-loop pattern is a separate orchestration loop: run work, evaluate it, feed failures back, repeat until pass or stop criteria.
• Claude Code separates permission mode from lifecycle automation too: permission modes control asking/accepting/bypassing, while hooks such as PreToolUse/PostToolUse/Stop/SubagentStop are where validators and review loops attach.

Product decision for v0.8.66

Visible work intent should collapse to a tiny set, likely:

• Plan: inspect, reason, propose; no direct mutation by default.
• Build/Act: execute the user's requested work using the selected execution posture.

Execution posture is a separate axis:

• approval policy: ask / auto-approve safe / bypass / never, using the existing enum where possible.
• trust/sandbox/network/shell posture: explicit capability boundary, not a hidden mode label.
• YOLO/high-trust: a posture that bypasses ordinary prompts, not a work mode.

MCP/Yolo expectation

When the user has explicitly chosen YOLO/high-trust/bypass, ordinary MCP tool usage should not keep asking for permission just because it is MCP. Exceptions still belong to the safety floor: auth/OAuth failures, publish-like actions, destructive or blocked policy outcomes, and any HoldForReview decision from auto-review must still prompt or block according to the active approval policy.

Prompt for implementation agent

You are fixing CodeWhale v0.8.66 mode/permission semantics. Start by auditing EffectiveModePolicy, mode picker copy, approval plumbing, MCP approval paths, and tests that mention auto_approve, trust_mode, approval_mode, allow_shell, YOLO, Agent, and Plan.

Implement the smallest safe change that makes there be one source of truth for prompting:

1. Remove auto_approve as an independent behavior flag or make it a derived compatibility field only.
2. Derive ordinary prompt bypass from approval_mode == Bypass or the existing explicit bypass policy, not from a separate UI mode name.
3. Stop using trust_mode as an implicit approval bypass. Trust should mean workspace capability/untrusted-workspace handling, not "skip every prompt" by accident.
4. Keep allow_shell only where it still carries distinct meaning; otherwise document why it remains.
5. Update mode picker/setup copy so it presents work intent and execution posture as two axes. Do not introduce or advertise Auto mode in v0.8.66.
6. Verify MCP approval prompts obey the same approval policy as other tools: YOLO/high-trust should not ask for ordinary MCP calls, while auth failures and auto-review holds still stop correctly.

Acceptance additions

• Mode/approval tests prove Plan cannot mutate by default.
• Build/Act plus ask-first posture prompts normally.
• Build/Act plus bypass/YOLO posture does not prompt for ordinary MCP calls.
• Publish-like, blocked, auth-failed, and HoldForReview outcomes still prompt/block even under high-trust where the safety floor says they must.
• UI copy never implies true Auto exists yet.
• Migration preserves existing user config behavior where possible and documents any rename/compat shim.

True Auto should mean a bounded review-repair loop, not a label on the mode picker. Track that in the future workflow/WhaleFlow lane, not here.

Refs: #3144, #3406, #3829.