The most dangerous moment in a long-running session isn’t when it starts.

It’s when it’s 40 minutes in, you’re on your phone, and it asks for something that could actually break your environment:

• install a system dependency
• delete or rewrite a directory
• modify secrets/config
• run a command you wouldn’t run casually

At that moment you have two bad instincts:

• approve fast because you want it to keep going
• deny everything because you don’t have the context to judge it

What I want instead is a workflow that makes approvals:

• explicit
• reviewable
• time-bounded when necessary
• and usable from a phone

TL;DR

1. Reduce blast radius first (so approvals are less scary): safer delete wrappers, strict sudo/doas rules, and narrow permissions.
2. Use a real “pause until human approves” pattern for risky steps (workflow interrupts / approvals).
3. If you want phone-first approvals with context, you need an approval UI that is durable (not a modal you miss).
4. Happier is one option that helps here because it treats approvals/requests as durable Inbox items, and permission modes let you choose how strict to be.

The problem

The core tension is simple:

• you want Claude Code / Codex / OpenCode to have enough power to be useful
• you don’t want it to have enough power to ruin your day while you’re away

That tension doesn’t get solved by one toggle.

It gets solved by layers.

What I tried first (and where I bounced off)

• Go full YOLO: it works until it doesn’t.
• Never allow writes: safe, but too limiting.
• SSH in and decide from the terminal: safe, but it turns into doing real work on a phone.

What ended up working for me was combining:

• blast-radius reduction
• explicit human-in-the-loop pauses
• a phone-friendly approval UI

Happier is one tool that bundles those last two pieces.

Layer 1: reduce blast radius so approvals are less scary

These are boring, but they matter.

• Use a safer rm wrapper (safe-rm) so accidents are reversible.
• Use strict sudo defaults and logging.
• Consider doas if you want simpler, explicit rules.

This doesn’t replace approvals.

It just makes “one mistake on mobile” less catastrophic.

Layer 2: time-bounded access approvals (when you’re on shared or sensitive machines)

In bigger setups, approvals often gate access, not individual commands.

Teleport-style access requests are the canonical example:

• request a role/resource
• someone approves
• it expires

It’s heavy for a personal dev box, but the model is worth understanding: approvals are strongest when they are time-bounded and auditable.

Layer 3: workflow interrupts (pause until you approve)

If you want approvals at the action level, the pattern is:

• the workflow reaches a risky step
• it pauses
• you resume it with a human decision

This exists in agent orchestration frameworks (interrupts).

The trade-off: you need reliable notification + resume semantics.

The Happier workflow (durable approvals + permission modes)

Happier splits two related concepts:

• Permissions: how often you’re asked (Default / Read-only / Safe YOLO / YOLO)
• Approvals: durable review points in Inbox for actions that should not run immediately

Inbox matters because it’s a real “attention list.”

It’s not a transient modal.

So on a phone you can:

• open Inbox
• review the request in context
• approve/deny

Practical rules I use (phone approvals)

• If I don’t understand the request in 30 seconds, I don’t approve it.
• I ask for:
  • a one-line explanation
  • the exact command
  • the exact path
  • what changed recently
• I use Safe YOLO more than YOLO.

Related guides

• Stop “waiting for approval”
• How to approve Claude permissions from your phone
• How to tell which session is stuck