Pending queue

What is the pending queue?

The pending queue lets you store messages for a session without sending them to the agent immediately.

Pending messages are:

• Session-wide: anyone with edit access to a shared session can see and manage them.
• Ordered: you control the order they will be processed.
• Editable: you can edit, remove, or reorder them before they run.
• Stored with the session: pending content uses the same storage mode as the session transcript (encrypted by default, plaintext on deployments that use plaintext storage).

Pending messages do not affect “unread” indicators. Instead, you’ll see a separate pending count badge.

Where you’ll see it

Session list badge

In the session list, sessions with pending messages show a pending count badge (for example 3 or 99+).

In the session view

When a session has pending messages, a “Pending (N)” indicator appears in the session view. Tap it to open the Pending messages sheet.

For a resumable inactive session, the composer stays available even when its machine is offline. Sending stores the message durably in this queue instead of pretending the session is online. A composer banner then shows the recovery state:

• waiting for the machine to reconnect under the selected automatic-resume policy,
• reachable and waiting for the daemon to start the session,
• kept queued for manual resume, or
• unable to start, with an explicit retry action.

For a manually queued offline message, Process when online authorizes automatic processing for that exact message without changing the account setting. The banner also lets you keep the exact message queued or open Auto-resume options. A start failure is not retried indefinitely; reconnecting alone does not restart a failed request.

Managing pending messages (UI)

Open Pending messages from the session view indicator.

Pending messages actions

For each pending message you can:

• Move up / Move down: changes the order the agent will process messages.
• Edit: update the message text before it runs.
• Remove: deletes the pending message (it won’t be processed).
• Send now: stops the current turn and sends the message immediately.

Discarded messages

Sometimes messages end up in the Discarded messages section (for example, when switching a session from remote to local and the pending queue must not be processed).

From Discarded messages you can:

• Re-queue: move the message back into the pending queue.
• Remove: permanently delete it.
• Send now: send it immediately.

Message sending settings

Go to Settings → Session → Message sending.

Automatic resume after sending

This setting applies when you send to a resumable inactive session:

• Now or when machine returns: Happier queues the message and authorizes the owning daemon to resume that session. If the machine is offline, the request remains parked until its daemon reconnects.
• Only if machine is online (default): Happier makes one resume attempt when you send and only if the exact machine is currently reachable. If the machine is unavailable or the attempt races with a disconnect, the message stays queued and does not authorize a later automatic start.
• Never automatically: Happier queues the message without requesting a session start. You can resume it explicitly from the composer banner later.

Changing the setting affects future sends only. It does not silently cancel or create a start request for messages already queued. The banner’s Process when online action applies only to the exact queued message shown.

Queue in agent (current)

Default behavior when everything is online:

• your message is written to the transcript immediately
• the agent processes it when ready

Safety fallback:

• if the session is offline, resuming, or the agent is not ready yet, Happier may store the message in the pending queue first to avoid losing it.
• if the session is currently under local control during an attach/local-control flow, Happier queues the message until the session is ready to resume remote processing.

Interrupt & send

Aborts the current turn (if any), then sends your message immediately.

If the session needs to resume (or is offline), Happier may store the message in the pending queue first and then deliver it once the agent is ready.

Pending until ready

Stores your message in the session’s pending queue and lets the agent pull it when ready.

This is the best option when you want to:

• queue up multiple messages and control their order,
• keep messages editable until the agent starts processing them,
• avoid losing a message when the agent is offline or not ready yet.

Local-control sessions

Local control means the provider TUI is active in your terminal. Remote control means Happier is driving the same provider session in the background for the app.

For Claude, and for Codex sessions on Windows, using ACP, or using an older Codex CLI, local control is exclusive. While the provider TUI owns the session, Happier does not inject app messages directly into that terminal process. Instead:

• the app stores the message in the session pending queue,
• the local Happier process watches for pending messages,
• if no local turn is running, Happier can switch the session back to remote processing and deliver the queued message,
• if a local turn is still running, Happier waits for that turn to finish, abort, or exit before switching back to remote.

This avoids interrupting an in-progress local Claude or Codex turn. Without this wait, sending an app message into a busy terminal TUI could cancel or corrupt the current provider turn.

For OpenCode, and for App Server sessions using Codex CLI 0.131.0 or newer on macOS or Linux, local control is shared. The provider TUI and Happier app stay connected to the same provider session, so app messages do not need the exclusive-control handoff path merely because a TUI is attached.

You can always review queued messages from the Pending messages sheet before they run.

Mixed-version behavior (server / agent compatibility)

The pending queue feature requires support from both:

• the server (pending queue endpoints + updates), and
• the agent/CLI that processes sessions (must know how to materialize pending into the transcript).

If your setup doesn’t support pending queues, the app will fall back to the normal message sending behavior and you won’t be able to rely on pending queue actions.

Automatic reconnect resume additionally requires a current server and the daemon on the session's exact owning machine. With an older server or daemon, Happier keeps the existing direct-resume compatibility behavior instead of assuming that unattended activation is available.

Tips

• If you’re queuing multiple thoughts, use Move up / Move down to ensure the agent processes them in the intended order.
• If you decide something is no longer relevant, Remove it before it runs.
• If you need something handled immediately, Send now is the fastest path.
• During local to remote switching, a short queued or waiting state is normal and helps avoid losing messages or interrupting an active local turn.