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.
- 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
- Decide what you need:
- Queue until ready (ordered, editable follow-ups), or
- Interrupt & send now (stop the current turn)
- 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.
- 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:
- How to run Happier from your phone
- GitHub: https://github.com/happier-dev/happier
- Install/download: https://github.com/happier-dev/happier#how-it-works
- Discord: https://discord.gg/W6Pb8KuHfg
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.