send-at

send-at — timed prompt delivery into one exact cmux surface

Deliver a prompt into a specific existing cmux surface, identified by its UUID, at a target time — while this agent session stays alive. The surface UUID is the whole address: no prior hotline connection, no cached session, no discovery. This skill does the when (a harness-native in-session wait) and hands the what/where to a deterministic delivery script.

Read this first — the honest reliability envelope

This is a same-session, best-effort timer, not a durable scheduler. It fires the delivery only if this agent process and the Mac are still alive at the target time. That boundary is not a limitation to fix later — it is forced by two hard constraints working together:

• The delivery must run from a process with cmux ancestry. cmux's socket defaults to cmuxOnly: only processes cmux itself spawned may drive it. The agent's own shell (Claude's Bash tool / Codex's exec cell) has that ancestry; a launchd/cron job or a cloud routine does not — cmux refuses them. So the thing that fires the send has to be this agent, in this pane.
• Nothing that outlives this process can wake this process in-pane. An external timer (launchd/cron) has no cmux ancestry, and a cloud-scheduled agent runs off-machine with no socket at all. Both are excluded. So the only clock we can use is one that keeps this session waiting.

Consequences to state plainly to the user before scheduling anything far out:

• Short horizons (seconds to ~1 hour, up to a few hours if the Mac stays awake) are the honest sweet spot. An "at 9am tomorrow" ask cannot be made reliable here — say so and point at a durable OS/cloud scheduler if they truly need overnight delivery (accepting it then can't target a cmux surface for the ancestry reason above).
• If the session is closed, the agent is interrupted, or the Mac sleeps through the target, nothing fires. There is no catch-up.
• Delivery itself is best-effort, not verified (V1 has no nonce/transcript check). cmux send can sporadically fragment or drop bytes (not size-gated), a busy REPL silently enqueues the message, and a user-scrolled viewport hides it. The read-screen check is therefore informational — "not observed" is never proof the send failed.