Never lose a follow-up: durable queues + interrupts for Claude Code, Codex, and OpenCode sessions

A practical way to send follow-ups from your phone while a session is busy/offline, without dropping messages or creating a second “shadow plan” in notes.

Based on
CLI
0.1.0
Preview ref
f36aa45

The most common way I accidentally derail a session is not by sending the wrong instruction.

It’s by sending the right instruction at the wrong time.

A session is busy (or offline / resuming), I fire off a follow-up from my phone, and then one of three things happens:

  • the message disappears into the void
  • it lands later than I expected (after the session already made a bunch of decisions)
  • I don’t trust it, so I write a second “shadow plan” in Notes… and now I’ve created a coordination problem with myself

What I want is boring:

I want to queue follow-ups safely, edit them if I change my mind, and send-now only when I truly mean “interrupt.”

TL;DR

  1. Decide what you need:
    • Queue until ready (ordered, editable follow-ups), or
    • Interrupt & send now (stop the current turn)
  2. If you don’t have a durable queue, your safest fallback is: write the follow-up somewhere else and send it only when you’re sure the session is ready.
  3. Happier is one option that solves this directly with a pending queue (queue/edit/reorder/remove/send-now) that’s stored with the session.

The problem (in plain language)

When you’re not at your laptop, follow-ups are how you keep work moving.

But most tools treat “send a message” as if the receiver is always ready.

In real life the receiver is often:

  • mid-turn
  • disconnected
  • switching between local and remote control
  • resuming after being inactive

So you need a workflow that is explicit about time.

What I tried first (and where I bounced off)

  • Just send it and hope: surprisingly fragile.
  • Write it in Notes/Slack and remember to send later: works, but now I’m managing a second queue.
  • SSH into the machine and intervene directly: powerful, but it turns into real work on a phone.

If you want the industrial version of this problem, people solve it with durable workflow engines (Temporal) or agent orchestration frameworks with persistent threads and interrupts (LangGraph).

Happier is the “practical UX” version I use day-to-day.

If you’re new to Happier (what it is, and where to get it)

If you haven’t seen Happier before: it’s an open-source companion app (mobile/web/desktop) for sessions like Claude Code, Codex, and OpenCode.

The workflow is: sessions run on a machine you trust, and Happier is where you send follow-ups from your phone — with a real queue when the session isn’t ready.

Get set up:

Two modes that fix 90% of the confusion

Mode A: queue until ready

This is for:

  • you have multiple thoughts
  • you want ordering
  • you want to edit before it runs

Mode B: interrupt & send now

This is for:

  • “stop what you’re doing and answer this”
  • safety interventions
  • time-sensitive corrections

The trap is using Mode B as your default; it creates churn.

The Happier workflow (Pending queue)

Happier’s pending queue is explicit about the thing that matters: the session might not be ready.

Pending messages are:

  • ordered
  • editable
  • stored with the session

And they show up as:

  • a pending badge in the session list
  • a “Pending (N)” indicator inside the session

Actions you can take:

  • move up/down
  • edit
  • remove
  • send now

There’s also a “discarded messages” area for cases like local↔remote switching where the queue must not be processed automatically.

How this interacts with steering and attach/local control

Steering and pending queue solve different problems:

  • steering is for “inject into the active turn” (when supported)
  • pending queue is for “ordered, editable messages before execution”

During attach/local control flows, it’s normal for app-sent messages to sit pending until the session is ready to resume remote processing.

Troubleshooting

My follow-up didn’t run

Check:

  • is the session offline/resuming?
  • is the message sitting in pending?
  • are you currently under local control (attach)?

I keep interrupting sessions by accident

Change your default message sending setting to a queue-first mode, and use send-now only intentionally.

mobilemessagesqueueclaudecodexopencodeworkflows
Last updated: 2026-04-03