--- title: Waiting detector (part 2) --- # Waiting detector (part 2) ## What it is This is part 2 of the [Waiting detector](waiting-detector.md) page. It covers the far end of a wait — the cap that finally surfaces a session to your inbox, the agent-stated ETA that replaces the default window, the two buttons that extend or prod a wait by hand, the automatic check-ins that fire before and after the inbox, the actions you can take straight from the inbox row, and the hidden confirmation that stops the detector acting on a guess. ## Where to find it The same surface as the [parent page](waiting-detector.md): the session chat, where the orange **⏱ Auto-waited** pill sits above the agent reply that fired and the **Keep waiting** and **Check in** buttons sit above the message box; the **Needs You** inbox row and its right-click menu; the controls under **Settings → Sessions**; and the audit log at **Settings → Diagnostics → Waiting Detector activity**. ## How it behaves ### How to use it #### What happens at the cap The cap timer **only ever fires after a genuinely silent wait**: any fresh agent activity (a new tool call, more output) disarms it, and a still-waiting turn re-arms a fresh window. So a fired timer means the agent declared a wait and then went silent for a full 30 minutes with nothing new. When that happens, Omniscio clears the deferred state and **surfaces the session to your inbox** — it flips to **Needs You** with the `wait_timeout` reason and writes a clear system line: ``` Auto-wait timed out — no new activity for 30 minutes (was waiting on: "…"). Surfacing to you. ``` That's it — no re-prompt, no re-arm (with **Auto check-in** off, the default; turn it on and the cap instead checks in with the agent up to 3× before surfacing — see "Let it check in for you" below). A genuinely stuck wait reaches you within one 30-minute window; a healthy session that's still working is never surfaced, because its activity keeps resetting the clock. > **Why this changed (2026-06-09).** Earlier builds instead re-injected a nudge prompt at the cap and, if the agent re-declared waiting, armed _another_ 30-minute timer — with no limit on how many times that could repeat. A genuinely stuck session could therefore re-wait for hours; the worst observed case sat auto-waiting for ~49 hours. Every other auto-recovery path in Omniscio is bounded, so this one was brought in line: the cap now surfaces instead of re-arming. > **Also — interrupted waits recover silently (2026-08-11).** Some model providers — non-Anthropic engines that Omniscio drives through the Claude binary (e.g. DeepSeek, Kimi) — drop the connection mid-turn far more often than Anthropic's. Previously, when that happened _while_ a session was waiting on a background job, the session would briefly flip to your inbox and then recover on its own — over and over, every few seconds, for the whole wait. Now, once a wait is genuinely underway, Omniscio quietly **continues** it (re-running the session if its process was reclaimed mid-wait) instead of flapping it into your inbox — while still surfacing for real if the wait hits its time limit (the 2h/6h ceiling above) or genuinely can't be resumed. > **Long healthy waits get a card, not an interruption (2026-08-23).** A session that keeps *working* — checking its background job every cycle — can legitimately wait for hours (a slow or wedged cloud-CI gate). Omniscio no longer pulls such a session into your inbox when it crosses the 6-hour mark: it **keeps it running** and raises a single non-blocking **inbox card** with a link to the session and its status (how long it's waited, what it's waiting on), so you're told without being interrupted. The card clears itself when the session resumes or finishes. Only a session that has genuinely gone *silent* (no activity for ~2h) still reaches your inbox as **Needs You** — now with a clearer "it may be stuck" message — and a session whose process has genuinely died is still auto-restarted to try to revive it first. (Escape hatch: `AMC_DISABLE_AUTOWAIT_CARD=1` restores the old surface-at-6h behavior.) #### When the agent says how long — the ETA suffix (2026-07-07) The canonical keep-alive sentence Omniscio instructs agents to emit — _"Waiting on a background process to finish — I'll continue once it completes."_ — can now carry an optional **ETA**. When the agent can estimate how long the work will take, it appends `ETA minutes.` to that sentence, e.g. _"Waiting on a background process to finish — I'll continue once it completes. ETA 5 minutes."_ When it does, two things change for that one wait (and nothing else): - **That ETA becomes the wait window — plus a cushion** — instead of your configured waiting period. The agent's estimate is usually optimistic, so Omniscio adds a small proportional buffer on top: 20% of the estimate, but never less than +3 minutes and never more than +20, then clamped to the 5–240 range. So an agent that says _"ETA 5 minutes"_ is held for 8 minutes (5 + 3), one that says _"ETA 30 minutes"_ for 36 (30 + 6), and one that says _"ETA 60 minutes"_ for 72 even if your period is shorter. The agent told Omniscio when it'll be done, so Omniscio uses that estimate (cushioned) for this wait. The banner Omniscio posts appends a short note — _"Agent-estimated wait; Omniscio will check in with the agent when the time is up if the work isn't finished."_ — and always shows the final number, so what you read matches the timer. - **Omniscio checks in at the ETA — and keeps checking in for as long as the agent is working** — instead of dropping the session in your inbox, it sends the agent the same check-in the **Check in** button sends, automatically, and keeps the session running. This happens **regardless of whether "Auto check-in on waiting sessions" is on** — by stating an ETA the agent explicitly asked for a nudge, so the global opt-in toggle (which gates only _unsolicited_ prods) doesn't gate it. It stays bounded so a genuinely stuck wait always reaches you, but it no longer surfaces a session that's actually making progress (updated 2026-07-09). The session surfaces to your inbox when EITHER: it has gone **2 hours with no real work** — the agent kept re-declaring the wait but ran no commands, i.e. it looks stuck — OR the whole wait-chain has run **6 hours** total (a hard backstop so it can never loop forever), whichever comes first. As long as the agent keeps doing real work between check-ins (running commands, reading results), that 2-hour "idle" clock resets each time, so an actively-working session is **never** dumped in your inbox. And when it does surface, the message tells you what actually happened — _"Checked in with the agent periodically for ~2 hours, but it hasn't made progress in the last 120 minutes. Surfacing to you."_ — instead of a bare "no new activity" timeout notice. When the agent can't estimate, it omits the ETA — and as of **2026-08-15 (`a-recoverable-zombie-is-re-held`)** the bare canonical sentence gets the **same** treatment: because the standardized "I'm waiting" sentence _is_ the agent's explicit keep-alive, Omniscio checks in on it periodically (bounded by the same 2h-idle / 6h-total ceilings) **regardless of the "Auto check-in" toggle** — the ETA now only refines the window, not _whether_ the session is held. So a legitimately-waiting session no longer surfaces at the first 30-minute cap just because the model didn't append a number (this closed a gap where e.g. `codex`, which never emits an ETA, always surfaced). A non-sentinel "waiting"-ish phrase still obeys the toggle. See [waiting-detector-contract.md](/.claude/memory/contracts/waiting-detector-contract.md) invariants **`a-declared-eta-sets-the-window`** + **`a-recoverable-zombie-is-re-held`**. #### A paraphrased keep-alive holds just like the exact phrase (2026-08-14) Agents don't always emit the exact factory keep-alive sentence — they paraphrase it, naming the real jobs and using "they": _"Waiting on the lint + test runs to finish — I'll continue once they complete. ETA 6 minutes."_ Omniscio already recognized that shape for the ordinary keep-running decision, but the **backup safety-nets** that catch a keep-alive when the normal detector is momentarily bypassed — most often right after the app restarts and auto-resumes a session — only recognized the byte-exact phrase. So a paraphrased keep-alive posted in that window slipped through to your inbox instead of holding (a real case: a freshly restart-recovered session flipped to the inbox 0.3 s after posting exactly that message). Now a paraphrased keep-alive gets the **same** safety-nets as the exact phrase — it holds the session **Running** (⏱ Auto-waited), honors its stated **ETA**, and the trailing "ETA N minutes." is treated as a positive keep-alive signal rather than noise. Every "a real question always reaches you" guard is unchanged: a turn that asks you something, or says _"…once **you** approve"_, still surfaces. (The one edge: if the app had **fully** killed the session's process, the paraphrase gets the same self-healing, auto-recovering _needs-you_ the exact phrase gets there — a brief, recoverable surface, not a silent hold.) Mechanics + the read-only backtest (0 false holds across ~9.7k real replies): [waiting-detector-contract.md](/.claude/memory/contracts/waiting-detector-contract.md) ("Keep-alive-close PARITY"). #### Give it more time — "Keep waiting" (2026-06-10) A timed-out wait stands out in a **bright orange** in your inbox and sidebar (the "stuck — needs a check-in" orange — brightened 2026-06-11 so it reads clearly, and distinct from the normal amber **Needs You**). Open the session and you'll see a **Keep waiting** button right above the message box, next to the usual Continue / Retry buttons. It shows its **own** configured length — **Keep waiting 60 min** by default — set **separately** from the initial waiting period at **Settings → Sessions → "Keep-waiting button duration (minutes)"** (`keepWaitingMinutes`, default **60**, range 5–240; added 2026-06-17). That's deliberately distinct from the 30-min "Waiting period" (the first wait): by the time a session lands in your inbox it has already waited one full window, so "Keep waiting" defaults to a longer second window — change either independently. One click puts the session back to **Running** for one more silent window of the Keep-waiting button's length (60 min by default) — it does **not** poke the agent, it just says "don't bug me yet." The button label and the actual timer always read the same number, so they can't disagree. If that window also passes with no new activity, the session surfaces again exactly as before and the button comes back, so you can keep extending it one window at a time. (As always, you can instead just type a message, or stop the session.) Clicking the button also **carries you on to the next session that needs you** — the same auto-advance you get from archiving or snoozing a session (2026-06-11). Keeping a session waiting is a triage step: you've parked it for another window, so Omniscio moves you forward to the next attention item instead of leaving you staring at an empty "All clear". If nothing else needs you, you land on "All clear" as before. The advance happens wherever the kept session is the one you're looking at — both in the Inbox and inside a project. (Renderer-only behaviour: the 30-minute reset itself is unchanged.) This is the deliberate, you-in-control version of the unbounded auto-re-arm that was removed 2026-06-09: the old behavior could re-wait for hours on its own; this only ever waits another 30 minutes, and only because you asked. #### Or prod it now — "Check in" (2026-06-11) Right beside **Keep waiting** is a **Check in** button — the opposite choice. Instead of buying the agent more quiet time, it pokes the agent _now_ with a short check-in: look at whatever you're waiting on and either keep going if it's ready, keep waiting quietly on your own if it's genuinely still in progress (no need to message me back), or stop and say what's wrong if it's actually stuck. Reach for it when the 30 minutes are up and you'd rather the agent take stock than wait another half-hour. Under the hood it's the same one-click "continue" every other recovery button uses — just with wait-aware wording — so the agent resumes right where it left off. It doesn't touch the waiting detector: a "still working" reply stays silent through exactly the same machinery described above. #### Let it check in for you — Auto check-in (2026-06-17, opt-in, default OFF) Everything above is **you** clicking. **Auto check-in** does that for you. Turn on **Settings → Sessions → "Auto check-in on waiting sessions"** (`autoNudgeEnabled`, **default off**) and, when a silent wait hits its cap, Omniscio sends the agent the **same** check-in the **Check in** button sends — automatically — instead of dropping the session in your inbox right away. Because Omniscio is sending it on its own, the automatic check-in opens by identifying itself as Omniscio (not you), so the agent never mistakes the prod for a message you typed; the manual **Check in** button you press stays a plain, unlabeled check-in. If the agent is still genuinely waiting, it keeps waiting quietly and Omniscio checks in again at the next window; if it's stuck or done, it surfaces. It is **bounded** — this is the whole point. Omniscio will check in on a session at most **3 times in a row** (one waiting-period apart); after that, or the moment the agent makes real progress, the budget resets. If it's still stuck after the third check-in it surfaces to your inbox exactly as it would today. So a stuck session always reaches you within a few windows — it can **never** loop forever the way an older unbounded auto-re-arm once did (the ~49-hour case that behavior was removed for, 2026-06-09). Each auto check-in shows a small ember **⏱ Checked in (N of 3)** tag right on the check-in message in the chat — the same style as the ⏱ Auto-waited tag — so you can see it happening, and the check-ins are marked as automatic so they don't count toward cost tracking. Off-switch if you ever need it: `AMC_DISABLE_AUTO_NUDGE=1`. Leave the toggle off (the default) and nothing changes — a timed-out wait surfaces to your inbox as described above. #### Check in even after it's in your inbox — Inbox auto-check-in (2026-06-30; default ON / opt-out since 2026-07-05) "Auto check-in" above acts at the cap, _before_ the session lands in your inbox. But once a wait does surface, it sits in your inbox until you get to it — and if you're away, that can be a long time. **Inbox auto-check-in** is the mirror: it checks in on a session that has _already_ surfaced and then sat **untouched** in your inbox for a while. **On by default** (opt-out since 2026-07-05) at **Settings → Sessions → "Also check in after it's in your inbox"** (`inboxAutoCheckInEnabled`, **default on**). When a waiting session has sat in your inbox, with no action from you, for a configurable multiple of the waiting period, Omniscio sends it the **same** check-in the **Check in** button sends — automatically — and resumes it. If the agent is still genuinely waiting it keeps waiting quietly (and can surface + auto-check-in again); if it's stuck or done, it comes right back to you. - **How long it waits first.** The dwell is a **multiple of the waiting period** — **Settings → Sessions → "Check in after (multiple of the waiting period)"** (`inboxAutoCheckInMultiple`, **default 2**, range 1–10). With the default 30-minute waiting period, 2× means it auto-checks-in after the session has sat in your inbox for **60 minutes**. (It's the _waiting period_ that's multiplied, not the separate "Keep waiting" button length.) - **It only fires if you _haven't_ touched it.** At the moment the timer fires, Omniscio re-checks that the session is still sitting untouched in your inbox. The instant you reply, click **Keep waiting**, or otherwise act on it, any pending auto-check-in is cancelled — it will never check in on a session you've already handled. - **Bounded, the same anti-loop guarantee.** Omniscio will auto-check-in at most **3 times** on one stuck session; after the third, it **hands the session back to you with an explicit line** (2026-08-02) — a plain-language **⏱ Checked in 3/3 · your turn** summary saying it checked in automatically 3 times, it's still waiting on the same thing, and automatic check-ins are now paused (Check in to prod it, or Keep waiting for another window). This replaces the old generic "Auto-wait timed out — no new activity…" notice on that final surface, so the quiet stretch has a visible reason instead of the folded-away check-in history making it look like nothing happened. (Interim surfaces before the budget is spent, and the ETA-driven "checked in periodically…" surface, are unchanged.) The count resets the moment the agent makes real progress, or when you click **Keep waiting**. So a genuinely stuck session always stays in your inbox after a few tries — it can **never** loop forever. Each auto-check-in shows a small ember **⏱ Auto-checked in (N of 3)** tag right on the check-in message — the same style as the ⏱ Auto-waited tag; hover it to see how long the session sat in your inbox — and (like the pre-inbox auto check-in) it's marked automatic so it doesn't count toward cost tracking. This is independent of the pre-inbox **Auto check-in** above — you can run either, both, or neither. It's **on by default** (opt-out) as of 2026-07-05: a timed-out wait that sits untouched gets an automatic check-in. Turn the toggle **off** (or set `AMC_DISABLE_AUTO_INBOX_CHECKIN=1`) to restore the old behavior, where a timed-out wait simply waits in your inbox until you act. #### Act without opening the chat — inbox right-click menu + check-in-before-timeout (2026-06-14) The two buttons above used to live in only one place: the open chat, and only _after_ a wait timed out. Two changes put them where you actually meet a wait: - **In the inbox right-click menu.** When a wait times out and the session drops into your inbox, right-click the row and you'll see **Keep waiting** and **Check in** alongside Open / Dismiss / Snooze — extend or check in on the wait straight from the inbox without opening the session first. They appear **only** on a genuinely timed-out wait (a `wait_timeout` session); every other row's menu is unchanged. (These _briefly_ shipped as buttons sitting directly on the row, but an inbox row is a notification, not a control surface, so they moved into the menu — see [frontend-inbox-row-contract.md](/.claude/memory/contracts/frontend-inbox-row-contract.md) § "No inline controls in the inbox row".) The right-click menu is desktop-only; on a phone, open the session to reach the same actions in the chat. Clicking **Keep waiting** also carries you to the next session that needs you, same as in the chat. - **During the silent wait, before the 30 minutes are up.** The chat now also shows a **Check in** button _while_ a session is still silently auto-waiting (Running, ⏱ Auto-waited) — not just after it times out. If you can see it's waiting and you'd rather prod it now than wait out the window, one click does it. There's deliberately no **Keep waiting** button mid-wait — the session is _already_ waiting quietly, so the only useful action before the cap is to check in. Both reuse the exact one-click actions described above, so they behave identically wherever they appear. Source of truth: [waiting-detector-contract.md](/.claude/memory/contracts/waiting-detector-contract.md) (invariant **`wait-actions-reach-the-user-before-the-cap`**) + [frontend-inbox-row-contract.md](/.claude/memory/contracts/frontend-inbox-row-contract.md). #### Confirm ambiguous waits before interrupting — Tier-3 confirmation (Settings → Sessions, on by default) The detector has a confidence ladder. **Tier 1** is the exact keep-alive sentence AMC instructs agents to emit (_"Waiting on a background process to finish…"_) — it always auto-waits, silently. **Tier 2** is a clear paraphrase the high-precision tier catches. **Tier 3** is the ambiguous middle: a turn ends on _wait-ish_ wording that is **not** the exact sentinel and **not** a question or a _"waiting on you"_. Left unchecked, a Tier-2/Tier-3 guess would either silently park the session or flip straight to **Needs You** — either way a decision made on a guess. **On by default** (**Settings → Sessions → "Confirm ambiguous waits before interrupting"**, `waitConfirmEnabled`): on any non-sentinel wait wording, AMC runs a quick **invisible** check before deciding rather than acting on the guess — it keeps the session **Running**, waits ~2 seconds, and sends the agent **one** hidden confirmation asking whether it is genuinely waiting. Three outcomes: - The agent is waiting → it replies with the exact keep-alive sentence (optionally + an `ETA`), and the session **auto-waits** quietly (⏱ Auto-waited) — no interruption. - Nothing is coming back and you have nothing to decide, but there is something worth knowing → it replies `card: `, and that line becomes a small inbox card while the session rests out of your inbox (see "Only a decision interrupts you" below). - You have to **decide something right now** → it replies with the tiny token _"Not waiting"_, and AMC sends the **original** message exactly where it would have gone without the check — **Needs You** for your own sessions, its lead for a crew member, its Overseer for a session an Overseer owns. **The whole exchange is hidden.** The probe never renders (it's a system auto-response, already dropped from the transcript), and the _"Not waiting"_ reply is folded away — so on the not-waiting path you see your agent's original message surface as if nothing happened. It all completes **before** the session reaches your inbox, so there's never a premature "Needs You" flicker. If the agent returns a real, substantive answer instead of the tiny token, that answer is shown normally (never hidden). **It can never loop.** AMC asks **at most once** per wait — the probe budget is checked before it can reset, so a still-ambiguous reply can't trigger a second probe; it just surfaces. If the agent never answers the probe (its process hangs), a backstop surfaces your original message anyway (it never strands). Real questions and _"waiting on you"_ turns are filtered out **before** this ever runs, so they interrupt you exactly as today. **It also catches a _confident_ "won't poll"-style sign-off.** The check-in doesn't fire only on genuinely-ambiguous Tier-3 wording — it also intercepts a **high-confidence** poll-avoidance "guess" the detector would otherwise silently park (a _"won't poll"_ / _"standing by"_ / _"waiting on lint"_ that isn't the exact keep-alive sentinel). The rule is simple: **only the standardized keep-alive sentence holds a session silently; every other waiting phrase becomes a check-in.** So a finished turn that signs off with _"won't poll further"_ gets the quick hidden "are you actually waiting?", the agent says it's done, and your view surfaces immediately instead of sitting parked for the whole window. (This fixed a live case where a finished session's _"won't poll further"_ parked it 30 minutes.) Turn the setting **off** (or set `AMC_DISABLE_WAIT_CONFIRM=1`) to restore the old behavior — that guess parks silently as it used to. **It reads only the agent's real final message (2026-08-03).** All Gate-6 waiting classification now looks only at the text AFTER the agent's `[[OMNISCIO_FINAL]]` marker — its actual reply — never the hidden working notes above it. So a stray _"won't poll"_ buried in the agent's private reasoning can't trip a wait when the real reply is a clean "done." A no-op when the agent didn't use the marker (the whole message is scanned, as before). Off-switch: turn the toggle off, or set `AMC_DISABLE_WAIT_CONFIRM=1` — either restores the old silent-park behavior. Mechanics + invariants: [waiting-detector-contract.md](/.claude/memory/contracts/waiting-detector-contract.md) ("Tier-3 confirmation" + invariant **TC7**). #### A card that says "Wait" doesn't reach your inbox (2026-09-05) The same hidden check now also fires on the agent's **Plain Speak card**. When a session finishes a turn whose card's **Recommended Action** is **⏳ Wait**, the agent has told you, in its own words, that there is nothing for you to do — so sending it to your inbox would interrupt you only to say *sit tight*. Instead, Omniscio quietly asks the agent one question you never see: - **The agent really is waiting** on something it started → it replies with the standard keep-alive sentence (plus an ETA when it can estimate one) and the session parks quietly and keeps itself alive. You are not notified at all. - **Nothing is coming back and there is nothing for you to decide** → it replies with one line, `card: `, which shows in your inbox as a small card while the session rests quietly (see "Only a decision interrupts you" below). - **You have to decide something right now** → it replies with the single word _ignore_, and the **original message goes exactly where it would have gone without the check**, as written, seconds later: to Needs You for your own sessions, to its lead for a crew member, to its Overseer for a session an Overseer owns. Everything about it matches the check above: the probe and the one-word reply are both hidden, it can fire **at most once** per wait, a real question or a "waiting on you" turn is filtered out before it runs, and if the agent never answers, a backstop surfaces your original message anyway. The cost is one extra agent turn on a Wait card; the payoff is an interruption you never have to read. **It now works even when the CLI drops the turn (2026-09-06).** Claude Code normally tells Omniscio "this turn is finished"; occasionally — usually when the machine is busy — that signal never arrives, and a separate safety net decides what to do with the turn instead. That net only knew the keep-alive *sentence*, so a card saying **Wait** still went to your inbox, purely because of a hiccup the agent had no control over. On 2026-09-06 a session did exactly that: its card read *"Wait — test verdict still queued"* and it landed in Needs You anyway, while every other turn in the same session waited quietly. The Wait card now gets the identical hidden check on both routes, so the outcome no longer depends on whether that signal arrived. Off-switch: `AMC_DISABLE_PLAIN_SPEAK_WAIT_CONFIRM=1` disables just this card trigger and leaves the wording-based checks above working; turning the Tier-3 setting off disables all of them. #### Three ways a Wait card still reached your inbox, closed (2026-09-28) Wait cards were still turning up in the inbox (owner report). Measured over one day: of 784 turns carrying a Wait card, about 160 reached the inbox anyway. Three gaps accounted for most of them: - **A card that arrived late was never checked.** When an agent forgets its card, Omniscio quietly asks for it, and the card arrives one turn later. That late card was attached to the original message and the message was put straight back in your inbox — the Wait check never saw it (about 32 a day). A late card that says **Wait** now gets the same hidden check as any other. - **A crew member's "ignore" skipped its lead.** When a crew member answered the check with _ignore_, its report landed in your inbox or reached nobody at all, because the crew routing ignored the one-word reply and never looked at the report behind it (33 reports in one day). The report now goes to its lead, and a session an Overseer owns hands it to that Overseer. - **The question offered an easy way out.** The check used to let the agent say _ignore_ whenever you had "something to read" — which every status update does. Most of those agents were in fact waiting on another session to report back. _ignore_ now means you must decide, approve, answer or act on something, or nothing is still coming back to the agent. Two things were deliberately left alone. A card that says **Wait** while also asking you a question still reaches you, because a question always wins. And a crew lead's updates were already fixed separately the same day. #### A run paused at a gate is never asked to confirm (2026-09-28) The hidden check now stands down for one specific kind of turn: a **dev-pipeline gate report** whose card says **⏳ Wait**. Those cards read *Wait* because the *run* is paused between phases, not because the agent wants a background hold — and the check was actively harmful there. Probing one appends a one-word reply *after* the report, and the safety net that advances a stranded run only acts while the report is the session's **latest** message. So the check designed to keep you out of the loop was the thing putting these runs in your inbox. Measured over one day: **10 runs** had a probe land right after their gate report, **8** of those reports were ready to advance, and none of the 10 got an answer within five minutes. A gate report the pipeline is ready to advance is now left alone, and the run advances by itself. Nothing else changes — a **Wait** card on an ordinary turn is checked exactly as before, and so is one whose report is genuinely holding (waiting on a test verdict, say): those really do mean nothing is wanted from you, and the probe goes on protecting you from them. **The first version of that only covered the rarer route.** It stood the check down when the CLI dropped the turn's "finished" signal, but on the normal route the check still ran first, before the pipeline was even asked — so a run whose gate card said **Wait** sat on the hidden question instead of moving on, until a check-in or a person nudged it. Measured over one day: **40 of 59** ready-to-advance gate reports carrying a **Wait** card were stopped this way, across 27 sessions. Every route now stands down for a report the pipeline will advance — including a card that arrived one turn late, which is judged against the gate report it belongs to. #### Only a decision interrupts you — everything else can be a one-line card (2026-09-29) Surfacing a message costs you something: it lands in your inbox and stays there until you reply to it or snooze it by hand. So both hidden checks — the one for a **⏳ Wait** card and the one for wording that only sounds like waiting — now tell the agent that cost plainly, and keep the interruption for one case: **you have to decide something right now** (approve, choose, or answer). Everything else gets a lighter choice. The check offers three answers, least disruptive first: - **Still waiting** → the keep-alive sentence, and the session waits quietly, as before. - **Nothing is coming back and nothing needs deciding, but there is something to know** (for example, the work is finished) → the agent replies with one line, `card: `. That line shows in your inbox as a small card named after the session, with a **Go to Session** button, and you clear it with one click. The session rests out of your inbox, badge and chime until its next turn, with its full message waiting inside it. - **A decision is needed now** → _ignore_ (or _Not waiting_), and the original message reaches your inbox as it always did. A few details: - **One card per session.** A session's newest card replaces its last one instead of stacking, and dismissing a card never blocks the next one. - **Crews are unchanged.** A crew member's or an Overseer-run session's card answer still sends its full report to its lead or Overseer. - **When in doubt, you still see the message.** If the card can't be raised, or the turn has to reach you — your own message, a question, or a reply you are already owed — the original message surfaces exactly as before. - **It has its own switch.** The card is listed as **Session update** under Settings → Notifications → Alert types; mute it and card answers rest the session quietly with no card. - **Only an answer counts.** The `card:` reply is hidden like the other one-word answers, but only when the app actually asked — a `card:` line an agent writes on its own is shown as a normal message. ## Related The overview, the coverage of non-Claude engines and the everyday controls are on the [parent page](waiting-detector.md); [part 3](waiting-detector-part-3.md) covers what the detector deliberately never does, the optional AI second opinion, and the first half of the technical reference; [part 4](waiting-detector-part-4.md) covers the ScheduleWakeup check-in mode and the rest of the technical reference.