The notification when a thread finishes
With notifications on, the phone buzzes when a thread settles: the agent finished with nothing queued behind it, it crashed, it is blocked on an approval, or it is waiting out a usage limit.
Why you would use it
It is the point of turning notifications on. What matters is which endings buzz and which stay quiet, so the phone is worth listening to.
How to use it
- Turn notifications on for the device.
- Send work and put the phone away.
- Tap the notification when it arrives to land in that thread.
What you see
The notification's title is the thread's title plus what happened:
| Ending | Title | Body |
|---|---|---|
| Finished | <thread> — done |
the last thing the agent said, or Finished. |
| Blocked on an approval | <thread> — needs you |
the tool and target it is asking about |
| Held by a usage limit | <thread> — usage limit |
which limit, and when it comes back: Codex 5h usage limit reached · resumes automatically at 14:20 (in 2h 5m) |
| Crashed or exited | <thread> — failed / <thread> — exited |
the fault detail, or the agent stopped |
- The notification itself is drawn by the operating system, not by the app, so there is no screenshot of it here. What the app owns is the bell that turns it on — see turn-on-notifications — and the thread it opens when you tap it.
- The body is collapsed to one line and clipped at 180 characters with
…. - The icon is the app's own mark. On Android the small status-bar glyph is a white silhouette of the same mark.
- One live notification per thread: a thread that finishes twice replaces its own row rather than stacking, and the replacement still alerts.
- Tapping it dismisses it. If the app is open it comes forward on that thread; if
it is closed it opens on
/?thread=<id>, and the app strips that parameter after honouring it once. - In the app on app.v-code.dev every box on your account can notify you, once
it runs a release with the app's notifications. Tapping
opens the thread on the box it came from:
/?thread=<id>&box=<box id>when the app is closed.
What stays quiet:
- A turn that drains straight into the next queued submission.
- A turn with work still queued behind it.
- A turn you stopped by hand — you were holding the phone.
- A closed thread.
- The thread you are looking at, on the screen that is looking at it. Another device, or the same one with the screen off, still buzzes.
Limits and known gaps
- Two turns ending inside the 1200ms settle window produce one notification.
- A notification older than an hour is dropped by the push service (
TTL: 3600). A "finished" past that is noise. - A phone that was offline gets the latest state per thread rather than a screen
of stale ones: each push is topic-tagged
thread-<id>. - With nobody subscribed, nothing is sent and no key file is written.
- A push service answering 404 or 410 means that device is gone: the server drops the subscription. Any other failure (503, a timeout) keeps it.
- A payload the worker cannot read still buzzes, with a fallback title
VCodeand the bodyA thread finished.— a push that shows nothing makes Chrome post its own "this site has been updated in the background" instead. - Payloads are capped at the single-record size in
lib/push.js; an oversized one is refused rather than truncated.
Related
- turn-on-notifications
- where-notifications-work
- usage-limit-pause-and-retry
— the pause a
— usage limitnotification is about - stop-a-running-turn — the one ending that stays quiet on purpose
- close-and-reopen-tabs — a closed thread never notifies