feat(ai-vault-search): construct the session search indexer in the scanner service behind a setting by Jinwoo-H · Pull Request #20516 · stablyai/orca

Jinwoo-H · 2026-09-13T22:17:41Z

	Files	Added	Deleted	Net
Test	14	$\color{#1a7f37}{\Huge{\mathbf{+}}}$1277	$\color{#cf222e}{\Huge{\mathbf{−}}}$13	$\color{#1a7f37}{\Huge{\mathbf{+}}}$1264
Prod	31	$\color{#1a7f37}{\Huge{\mathbf{+}}}$1242	$\color{#cf222e}{\Huge{\mathbf{−}}}$173	$\color{#1a7f37}{\Huge{\mathbf{+}}}$1069

ELI5

Orca can already build a searchable index of your agent transcripts, but nothing on your
computer ever turned it on. This PR adds the switch and the plumbing behind it. The switch
is off, and there is no UI for it yet, so on a normal install nothing changes: the search
endpoints now say "off" instead of "this computer doesn't do that".

What Changed

Settings. src/shared/ai-vault-search-settings.ts holds { enabled, historyDays },
off by default, plus normalization and a Zod schema. GlobalSettings.aiVaultSearch persists
it through the settings IPC like any other field. There is no paused: the PR 3 indexer is
immutable, so every change is close-and-construct.

One instance per host. SessionSearchInstance holds at most one indexer + engine pair
and the three recipes: a settings change closes the pair and constructs a new one, disabling
closes with no replacement, clearing closes, removes the database and constructs again. The
database lives beside the scanner's parse cache, one file per host.

The scanner child owns it (desktop). The transcript reader runs in that child, so the
index consumer does too. Three new request operations (searchSessions, searchStatus,
searchReconcile) and one fire-and-forget settings message; main never opens the file. The
init frame became a factory so a respawned child reads current consent, and idle retirement
is suppressed while the index is on, because an indexing child is never idle from out here.

Registration on all three hosts. Desktop main forwards to the child. orcad and the SSH
relay daemon have no scanner child, so on those the instance lives in the process itself.
See "Deviations" below.

Measured. A committed benchmark prices a warm pass on 5,000 transcripts.

Why

Nothing constructs an indexer in production before this PR, so the search endpoints PR 5
shipped answer no-service on every host. no-service means "this host does not have the
feature", which is a different thing from "the index is off" and is what a client shows an
old host. Registering the service is what makes the second answer possible.

Deviations from the plan, and why

The relay and orcad do not use a scanner-service child, because they do not have one.
The plan says the scanner child owns the database on every host. That holds for the desktop.
It cannot hold for the other two:

config/scripts/build-orcad.mjs emits only the watcher and daemon children beside
orcad.js. getAiVaultServiceEntryPath() resolves to a path no orcad deployment contains,
so a child-backed service there would be registered and permanently broken.
The relay's AI Vault sidecar is a different entry and protocol
(src/relay/ai-vault-service-entry.ts). It runs scanRemoteAiVaultSessions through a
filesystem provider and publishes nothing to the transcript channel the index consumes.

On both, the process that would drive the index's own reads is the daemon itself, and it is
the only writer, so the two-process rebuild race the desktop rule avoids cannot arise. Both
are gated on node:sqlite: orcad's build comment states a deliberate Node 18 floor and the
relay is built target: node18, and node:sqlite needs 22.5. A host without it registers
nothing, which is the truthful no-service.

The relay registers with consent permanently off. Consent lives in GlobalSettings,
which the relay daemon does not read, and nothing carries a setting to a remote host yet.
Registering it anyway is still worth it: it is what lets a client tell "off" from "too old".
Turning it on needs a wire change and belongs with the UI.

No protocol operation for clear. SessionSearchInstance.clear() exists and is tested,
but nothing in this PR sends one, so no operation carries it. PR 8 owns the caller.

Three files hit the max-lines ceiling and were split rather than disabled around: the
invalidation deadline moved into the class that owns invalidations, call cancellation and
the start requeue into the call-state module, and orcad's flag parsing into its own file.

Linked Issue

Fixes #

Visual Proof

N/A: no UI. This PR adds no renderer code and no user-visible surface; the setting has no
control until PR 8.

Testing

Measured on this machine (Apple silicon, macOS), synthetic 5,000-transcript / 87 MB tree
under 40 project directories, three runs:

	run 1	run 2	run 3
cold build	4906 ms	4421 ms	4098 ms
warm full sweep	95 ms	148 ms	88 ms
warm cycle	86 ms	143 ms	75 ms

This is the number the 20 s reconcile interval should be revisited against. This PR does not
tune it.

Gates, all exit 0:

pnpm tc
pnpm test src/main/ai-vault-search src/main/ai-vault src/main/ipc src/relay src/main/orcad src/shared
pnpm run check:code-quality:changed
pnpm run check:react-doctor:changed
pnpm run audit:code-quality:type-aware
pnpm exec vitest run --config config/vitest.config.ts tests/e2e/cross-version-wire
pnpm run build:orcad
pnpm run build:relay

1415 test files, 14605 tests. The cross-version wire suite is 49 tests. Both bundle builds
were run because this change reaches the orcad and relay module graphs; build-orcad
re-confirms zero node:sqlite and zero electron imports in that bundle.

New coverage: the child booted over the real protocol with no renderer, reporting phase and
a live generation after one indexed transcript and answering search and reconcile; the
instance across off, on, narrow, widen, disable and clear; the main-side forwarder including
child-not-ready mapping; per-host registration; the client's index hold and per-spawn init;
settings normalization and the change hook.

Tested on macOS only. Linux, Windows, a live SSH relay and a real orcad deployment were not
exercised. No real transcript tree was read: every test uses a temp fixture root.

I manually tested these changes locally
Automated tests added/updated, or explained why not below

AI Disclosure

Review

Agent skill upstream boundary

Not applicable, or this change follows docs/reference/agent-skill-sharing-upstream-boundary.md and copies or mechanically translates no upstream skill-installer source, tests, fixtures, registry entries, path tables, comments, or documentation.

Notes

Security. Off by default; nothing reads a transcript until consent is recorded. The
index stores transcript content as written (decided 2026-09-09), under the same user-only
data root as the parse cache. Disabling does not delete it, which PR 8's consent copy has
to state.
Cross-platform. All paths through path.join. No platform-conditional behavior added.
Only macOS was exercised.
Remote SSH. The relay registers a service that is off and cannot be turned on; the SSH
leg's answer changes from no-service to disabled on a relay whose Node has
node:sqlite, and stays no-service otherwise. No wire change: the scanner-service
protocol is main-to-child on one machine.
Mobile. No change; mobile reads the same status endpoint through the runtime RPC.
Backwards compatibility. A profile with no aiVaultSearch key reads as off. The
scanner-service protocol version is unchanged because both halves ship in one binary.
Performance. Nothing runs on a default install. With the index on, a warm pass costs
the numbers above and the scanner child stops being retired after ten idle minutes.

Checklist

This PR is small and focused
I explained what changed and why (including ELI5)
Before/after screenshots or videos attached for UI changes, or N/A with reason
Self-reviewed for correctness, security, and performance
Cross-platform, SSH/remote, and path/shortcut impact considered (or N/A)
pnpm lint, pnpm typecheck, pnpm test, and pnpm build pass (or CI will cover; local preferred)

pullfrog

Important

One correctness gap in the child's settings path: a live indexer never picks up re-resolved scan roots. pushSessionSearchPolicy re-resolves them so "a distro started since boot must be in the new window", but SessionScannerServiceSearch.apply discards init.roots whenever an instance already exists. Details inline.

Reviewed changes

Settings + consent model. New off-by-default GlobalSettings.aiVaultSearch = { enabled, historyDays } with normalization (floor, clamp 3650, non-positive/NaN → null), a Zod schema and an equality helper (src/shared/ai-vault-search-settings.ts); persisted through the settings IPC, with the write hook in src/main/ipc/settings.ts.
One live pair per host. SessionSearchInstance holds at most one {indexer, engine, db} and implements close-and-construct for apply/disable/clear (session-search-instance.ts); retention cutoff is refreshed per search against the shared engine options object.
Scanner child owns the desktop index. Three new protocol operations (searchSessions/searchStatus/searchReconcile) plus a fire-and-forget sessionSearch message; init became a factory re-read on every spawn; idle retirement is suppressed while the index is on (session-search-child-service.ts, session-scanner-service-*.ts).
In-process registration for orcad and the relay. installInProcessSessionSearchService runs the instance in the daemon when there is no scanner child, gated on node:sqlite (session-search-in-process-service.ts, orcad-session-search.ts, relay-runtime-services.ts).
Scan-root extraction. localAiVaultScanRoots() was factored out of listAiVaultSessions and is shared by the list and the index (cached-session-list.ts).
Benchmark. A committed warm-pass benchmark over a synthetic 5,000-transcript corpus (config/scripts/session-search-pass-benchmark.ts).

ℹ️ Index database is created with weaker file permissions than the parse cache it sits beside

The index deliberately stores transcript content as written and unredacted (session-search-schema.ts), while the parse cache in the same <dataRoot>/ai-vault/ directory is written with PRIVATE_DIRECTORY_MODE = 0o700 and PRIVATE_FILE_MODE = 0o600 precisely because "the payload contains transcript-derived preview text; keep it user-only". openSessionSearchDatabase creates the directory with the platform default mode and lets SQLite create the .sqlite/-wal/-shm files with its default mode, so the index copies of transcript text can be more readable than the parse cache. This PR is the first that actually creates the file, so it is worth deciding whether the index should adopt the same 0o700/0o600 treatment or whether the userData root is trusted to already be user-only on every platform.

Technical details

# Index file permissions

## Affected sites
- `src/main/ai-vault-search/session-search-schema.ts` (`openSessionSearchDatabase`, `mkdirSync(dirname(path), { recursive: true })`) — no `mode`; SQLite's default file mode applies.
- `src/main/ai-vault/session-parse-cache-persistence.ts` (`persistSnapshot`, `PRIVATE_DIRECTORY_MODE`/`PRIVATE_FILE_MODE`) — the hardening the index lacks.

## Required outcome
- The index files should be user-only on POSIX, matching the parse cache's stated policy, or the PR body should record why the shared data root already guarantees it.

## Open questions for the human
- Is `getCanonicalUserDataPath()` guaranteed `0o700` on Linux/Windows, or is the parse cache's per-file hardening the only guarantee?

ℹ️ A child that faults while the index is enabled stays dead until some later request

AiVaultServiceSessionSearchHold stops idle retirement while consent is on, but it does not cause a respawn: a child error/exit reaches onFault, which schedules restartPolicy.recordFault(() => this.pump()), and pump() only calls ensureChild() inside the per-lane loop over queued calls. With an empty queue the timer fires into a no-op, so indexing stops until a later searchSessions/searchStatus request (or invalidate) happens to spawn a child. The class doc already notes indexing resumes on "some later scan", so this may be intended — flagging it because the hold's stated purpose is to keep the index alive, and no test faults the child while idle.

Technical details

# Idle fault leaves no scanner child

## Affected sites
- `src/main/ai-vault/session-scanner-service-client.ts` — `onFault` (schedules `pump`), `pump` (only `ensureChild()` with a queued call), `updateSessionSearch` (the only enabled-path spawn).
- `src/main/ai-vault/session-scanner-service-client-state.ts` — `AiVaultServiceSessionSearchHold.record` sets the flag but spawns nothing.

## Required outcome
- Either a fault while `holdsChild` should re-arm `ensureChild()` after the restart delay, or a comment/test should pin that recovery is deliberately request-driven.

## Open questions for the human
- Should the hold, like `updateSessionSearch`, own crash recovery for the index, or is lazy respawn acceptable because any status poll revives the child?

^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏}

…tion Two booleans and nothing else: `enabled` and `historyDays`, off by default because building the index reads every transcript on the machine. No `paused` -- the PR 3 indexer is immutable, so every change is close-and-construct. The settings IPC normalizes a write like every other field and hands the change to the index; there is no UI for it until PR 8.

The object that owns a host's live index and the three recipes that change it. The indexer is immutable, so a settings change is close-and-construct, disabling is close with no replacement, and clearing is close, remove the database, construct. The new instance's first sweep purges a narrowed window and admits a widened one, so neither needs a code path. The database sits beside the scanner's parse cache, one file per host. A runtime with no node:sqlite can hold no index at all, which the Node 18 floor on orcad and the relay makes a real case rather than a hypothetical one.

The transcript reader runs in that child, so the index consumer has to as well: one read serves both the session list and the index. Three request operations (search, status, reconcile) and one fire-and-forget settings message carry everything a parent needs; main never opens the database file. The init frame becomes a factory because it is read at every spawn, so a respawned child sees current consent rather than the first frame's. A child holding a running index is never idle from the parent's side, so idle retirement is suppressed while the index is on -- retiring it would stop the reconcile loop until some later scan happened to respawn one. Both files this lands in were already at the max-lines ceiling, so three collaborators move to where they belong rather than being disabled around: the invalidation deadline into the class that owns invalidations, call cancellation and the start requeue into the call-state module, and orcad's flag parsing into its own file.

…nswers Without a registered service a host answers no-service, which means "this host does not have the feature" rather than "the index is off". All three hosts now answer the second thing. The desktop forwards to the scanner child. orcad and the SSH relay daemon have no such child -- orcad ships only the watcher and daemon entries, and the relay's AI Vault sidecar runs the remote scanner, which publishes nothing to the transcript channel -- so on those two the index lives in the process that would drive its reads, gated on a runtime that has node:sqlite at all. The relay registers with consent off and no way to turn it on: nothing carries a setting to a remote host yet. That is the honest state, and it is still worth registering, because it is what tells a client the difference between off and too old.

The number the reconcile interval will be revisited against, measured rather than argued: a warm sweep stats every file under every root, a warm cycle stats the newest N per agent, and neither reads what the index already holds. It does not tune the interval.

main's new type-assertion rule reaches every file this branch touches. All nine sites drop the cast rather than carry a SAFETY: rationale: the operation guard narrows with `in`, the sqlite probe narrows the builtin it loads, the child test keeps the discriminated reply instead of widening it, and the settings resolver takes `unknown` -- which is what it really reads, since a persisted profile can hold a value no version of this code wrote.

Jinwoo-H · 2026-09-13T23:44:05Z

Rebased onto main, base retargeted

PR 5 (#20277) merged, so this branch now sits directly on main at 4eea86fa9a (six commits, clean rebase, no conflicts). The base was retargeted from session-search-pr5-contract to main.

Gate pass on the pushed head, all green:

Gate	Result
`pnpm tc`	pass
`pnpm test` (ai-vault-search, ai-vault, settings, ipc, orcad, relay)	731 files, 6,893 tests pass
`check:code-quality:changed`	pass
`check:react-doctor:changed`	pass
`audit:code-quality:type-aware`	pass
cross-version wire suite	pass
`build:orcad`, `build:relay`, `build:cli`	pass

Still inert on default installs: the setting is off and there is no UI to flip it, so every search endpoint answers unavailable/disabled instead of no-service.

Follow-ups recorded in the plan doc, not in this PR:

orcad runs the index in-process with synchronous SQLite writes; move it to a child if servers start enabling search.
The relay registers with consent permanently off; carrying the setting to a remote host is a wire change that belongs with the UI.

coderabbitai · 2026-09-13T23:56:18Z

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

@coderabbitai resume to resume automatic reviews.
@coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

▶️ Resume reviews
🔍 Trigger review

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Advanced

Run ID: 79209d1a-c16e-4444-aada-164b6aad5d83

📥 Commits

Reviewing files that changed from the base of the PR and between f0323b1 and db397e5.

📒 Files selected for processing (2)

src/main/ai-vault-search/session-search-enablement.ts
src/main/ipc/register-core-handlers/register-core-handlers.test.ts

Included review availability: Your plan provides up to 10 included reviews per hour; 6 remain after this review.

📝 Walkthrough

Walkthrough

The pull request adds opt-in AI Vault session search with normalized retention settings and a SQLite index. It adds session-search instances, scanner child protocol operations, in-process services, and host registration for desktop, Orcad, and relay. Settings changes update the index without unnecessary restarts. The change also updates scanner child lifecycle handling, extracts Orcad argument parsing, adds tests across the new paths, and adds a 5,000-session benchmark.

Priority: ➖ Normal

Merge Risk: 🟡 Moderate · up to db397

Cancelled searches may interrupt scanner availability, and concurrent root discovery may temporarily omit sessions from search results. These are bounded but material risks that should be resolved before merge.

🚥 Pre-merge checks | ✅ 3 | ❌ 2

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description covers the change, rationale, testing, visual proof, risks, and checklist. The required Linked Issue entry is incomplete because it contains only `Fixes #`.	Replace `Fixes #` with a valid issue reference, such as `Fixes` #123`` or the repository's accepted issue-link format.
Docstring Coverage	⚠️ Warning	Docstring coverage is 35.38% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 65 functions across 36 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly identifies the primary change: constructing the session search indexer in the scanner service behind a setting.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

Create stacked PR
Commit on current branch

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

coderabbitai

Actionable comments posted: 3

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Advanced

Run ID: 209b5ec5-c616-41b4-a1cd-622baf5af52a

📥 Commits

Reviewing files that changed from the base of the PR and between 5e70014 and 4eea86f.

📒 Files selected for processing (31)

config/scripts/session-search-pass-benchmark.ts
src/main/ai-vault-search/session-search-child-service.test.ts
src/main/ai-vault-search/session-search-child-service.ts
src/main/ai-vault-search/session-search-database-path.ts
src/main/ai-vault-search/session-search-enablement.ts
src/main/ai-vault-search/session-search-host-registration.test.ts
src/main/ai-vault-search/session-search-in-process-service.ts
src/main/ai-vault-search/session-search-instance.test.ts
src/main/ai-vault-search/session-search-instance.ts
src/main/ai-vault-search/session-search-policy.ts
src/main/ai-vault-search/session-search-service-init.ts
src/main/ai-vault-search/session-search-sqlite-support.ts
src/main/ai-vault/cached-session-list.ts
src/main/ai-vault/session-scanner-service-client-state.ts
src/main/ai-vault/session-scanner-service-client.test.ts
src/main/ai-vault/session-scanner-service-client.ts
src/main/ai-vault/session-scanner-service-entry.ts
src/main/ai-vault/session-scanner-service-protocol.ts
src/main/ai-vault/session-scanner-service-search.test.ts
src/main/ai-vault/session-scanner-service-search.ts
src/main/ai-vault/session-scanner-service-spawn.ts
src/main/ipc/register-core-handlers/register-core-handlers.ts
src/main/ipc/settings.test.ts
src/main/ipc/settings.ts
src/main/orcad/orcad-command-arguments.ts
src/main/orcad/orcad-entry.ts
src/main/orcad/orcad-session-search.ts
src/relay/relay-runtime-services.ts
src/shared/ai-vault-search-settings.test.ts
src/shared/ai-vault-search-settings.ts
src/shared/global-settings-types.ts

Included review availability: Your plan provides up to 10 included reviews per hour; 5 remain after this review.

The parent re-resolves scan roots before every policy push, precisely so a WSL distro or extra Codex home that appeared since the child spawned enters the window. The child forwarded only the settings to a live instance and used the roots solely in its `??=` initializer, so those roots were dropped for the child's lifetime. The indexer stays immutable: a structurally different root set closes the pair and constructs a new one, the same way a changed databasePath already does. Compare via `sameSessionSearchRoots` rather than a plain JSON compare, because nothing fixes the key order two producers write; lists are sorted too, since the indexer walks every root and a re-enumeration that reorders is not a change. An unchanged set still never restarts a running index. The orcad and relay in-process hosts resolve roots once at install and never re-apply, so they have no such seam.

pullfrog

✅ No new issues found.

Reviewed changes

Delta since the prior pullfrog review (66603554bf): commit c84c9c42ba fixes the one outstanding correctness thread, with no other changes to the branch.

Refreshed scan roots reach a live index. SessionScannerServiceSearch.apply now records the pushed roots and closes/rebuilds the pair when they differ structurally, instead of discarding them once an instance already exists (src/main/ai-vault/session-scanner-service-search.ts:43).
Structural roots comparison. New sameSessionSearchRoots compares key-sorted fields with list-sorted arrays and treats an absent key as equal to an explicit undefined, so a re-resolved root set that names the same trees stays a no-op (src/main/ai-vault-search/session-search-scan-roots.ts:146).
Coverage. session-scanner-service-search-roots.test.ts proves a root added after the child spawned becomes searchable and an identical set does not close the pair; unit tests pin the comparator's order/absence behavior. Focused run: 6/6 pass.

^{｜ View workflow run ｜ Using DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏}

Three review items. The hold keeps a child alive for the index, but only a queued call ever started one: `pump()` skipped a hold with an empty queue, so an idle indexing child that crashed, or an `ensureChild()` that failed at start, left indexing stopped until an unrelated request happened to arrive. `pump()` now starts the child the hold requires, which is also the restart callback the fault policy already schedules, so the existing delay and circuit bound the retry exactly as they bound a queued call's start. `updateSessionSearch` goes through the same seam instead of its own `ensureChild` call. A search registers no AbortController, so a cancel sent for a search id was added to the `cancelled` set and never consumed. Nothing can reach that today -- no caller passes a signal and the child answers in milliseconds -- so this is only a leak of ids: consume it when the search settles. The orcad argument doc claimed a `--`-prefixed value stays a flag. The parser takes the next token regardless, and orcad-launch-contract.test.ts pins that, so the doc is what was wrong. Behaviour is unchanged.

pullfrog

✅ No new issues found.

Reviewed changes

Delta since the prior pullfrog review (c84c9c42ba): commit 9885a731ef gives the index hold its own child restart and clears a cancellation-id leak.

Hold-owned child restart. AiVaultScannerServiceClient gains startSessionSearchChild() and calls it from updateSessionSearch and the tail of pump(). onFault's recordFault(() => this.pump()) now respawns an idle indexing child after the existing 250 ms/1 s/5 s backoff, so a crash while the hold is on no longer leaves indexing stopped until an unrelated request arrives. The guard (disposed || !holdsChild || child || readyWaiter) keeps it from racing a spawn already in flight for a queued call.
Search cancel ids no longer accumulate. session-scanner-service-entry.ts deletes request.id from cancelled in a finally around the search execution, since a search registers no AbortController for anything else to consume the id.
orcad flag doc corrected. orcad-command-arguments.ts now documents that a value-taking flag consumes the next token literally (--bind --json binds --json), matching what orcad-launch-contract.test.ts pins. No behavior change.
Coverage. New tests fault an idle child with the index on (asserts a respawn at 250 ms carrying current consent) and off (asserts no respawn), and existing client tests were updated to the new init factory. Focused run: session-scanner-service-client.test.ts 18/18 and session-scanner-service-search-roots.test.ts 2/2 pass.

^{｜ View workflow run ｜ Using DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏}

coderabbitai

Actionable comments posted: 1

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Advanced

Run ID: e39b5a33-e5e5-4525-b033-f677d23a7dda

📥 Commits

Reviewing files that changed from the base of the PR and between 9885a73 and f0323b1.

📒 Files selected for processing (5)

src/main/ai-vault-search/session-search-enablement.ts
src/main/ai-vault-search/session-search-host-registration.test.ts
src/main/ai-vault/session-scanner-service-client.test.ts
src/main/ai-vault/session-scanner-service-restart-policy.ts
src/main/ipc/register-core-handlers/register-core-handlers.ts

Included review availability: Your plan provides up to 10 included reviews per hour; 8 remain after this review.

pullfrog

✅ No new issues found.

Reviewed changes

Delta since the prior pullfrog review (9885a731ef): commit f0323b1 adds desktop-only periodic scan-root refresh and makes the held child's restart wait out the restart circuit. The prior idle-fault concern is now addressed end to end.

Periodic scan-root refresh on desktop. installChildSessionSearchService owns a 5-minute unref'd interval that re-resolves localAiVaultScanRoots() and pushes the init only when the root set changed structurally (session-search-enablement.ts). The timer starts on enable, is cleared on disable, and the returned disposer aborts an in-flight refresh so a late resolution cannot push after shutdown.
Restart waits out the circuit. AiVaultServiceRestartPolicy.recordFault now schedules the restart at Math.max(delay, circuitUntil - now), so a child faulting while the index holds it is respawned once the circuit expires rather than firing a restart the open circuit would reject and then leaving nothing to retry (session-scanner-service-restart-policy.ts).
Disposal wired at quit. registerCoreHandlers installs the desktop service beside the AI Vault handlers and disposes it on will-quit.
Coverage. New tests pin periodic refresh only-on-change, enable/disable timer lifecycle, abort-on-dispose, restart waits out the circuit (and dispose cancels it), and each host's boot path reaching an installer. Focused run: session-search-host-registration.test.ts 10/10 and session-scanner-service-client.test.ts 20/20 pass.

^{｜ View workflow run ｜ Using DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏}

pullfrog

✅ No new issues found.

Reviewed changes

Delta since the prior pullfrog review (f0323b1): commit db397e5 is a small refinement to the desktop root-refresh wiring plus a test-mock fix.

Policy reads deferred into the push. updateRootRefreshTimer now takes an explicit enabled argument and is called inside pushSessionSearchPolicy from the freshly read init frame (init.settings.enabled), instead of re-reading sessionSearchPolicy() from the install and settings-change paths (session-search-enablement.ts). The timer lifecycle is unchanged: starts when enabled, cleared when disabled, still driven by the same lastPushedRoots change gate.
AbortController replaced with a disposed flag. RootRefresh.controller becomes a plain boolean; the in-flight guard is still the post-await check, so disposal semantics are identical and one allocation per install is gone.
Test mock updated for the quit hook. register-core-handlers.test.ts's electron mock gains once, which the app.once('will-quit', …) wiring from f0323b1 requires. Focused run: host-registration 10/10, register-core-handlers 2/2, settings 35/35.

^{｜ View workflow run ｜ Using DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏}

Jinwoo-H · 2026-09-14T03:03:01Z

Codex review round + follow-up, head `705a35a5a2`

A Codex reviewer went over the whole diff for correctness, YAGNI and simplification. Two findings held up and are fixed; the rest were rejected on inspection.

Finding	Outcome
Three faults inside a minute open the restart circuit, but the restart timer fired at 5 s while the circuit stayed open for 60 s, so a held index never came back on its own	Fixed in `f0323b1542`: the restart delay is now at least the remaining circuit time. Test covers cooldown and disposal.
Scan roots were re-resolved only on a settings change, so a WSL distro or Codex home that appeared after boot was never indexed	Fixed in `f0323b1542` + `db397e5f16`: a five-minute refresh while enabled pushes only when the roots changed, cleared on disable and on quit.
The refresh state carried an AbortController for one boolean and read settings eagerly at install	Trimmed in `db397e5f16`.

705a35a5a2 then moved the service install from the desktop IPC registrar into the shared main-process runtime, so headless orca serve gets the same host-local service as the desktop; dropped the per-search retention-cutoff refresh so page cursors stay stable across pages (expiry rides the indexer purge, which already invalidates cursors); and short-circuits the root refresh when the setting is off.

Gate pass on 705a35a5a2, all green: pnpm tc; tests across ai-vault-search, ai-vault, shared, ipc, orcad, startup, relay (1,494 files, 15,351 tests); both changed-code gates; type-aware audit; cross-version wire suite; build:orcad; build:relay.

Still inert on default installs: the setting is off and there is no UI to flip it.

pullfrog

✅ No new issues found.

Reviewed changes

Delta since the prior pullfrog review (db397e5): commit 705a35a stabilizes pagination and moves host enablement to the shared boot path.

Retention window no longer refreshed per search. SessionSearchInstance drops refreshRetentionCutoff and the engineOptions/historyDays live-pair fields; the engine's retentionCutoffMs is fixed at construction (session-search-instance.ts:126). Pagination stays stable within a generation because the purge — which runs every pass, deletes expired files by files.mtime_ms, and bumps the index generation — also invalidates any cursor spanning it. The construction-time cutoff stays at or below the per-pass store cutoff, so the engine is never stricter than the purge and no stale rows outlive one. A new test crosses retention mid-pagination and still receives the next distinct hit at the same generation.
Disable applies without waiting on root discovery. pushSessionSearchPolicy reads the init frame up front and, when consent is off, clears the refresh timer and pushes the disabled policy immediately rather than first awaiting refreshSessionSearchScanRoots() (session-search-enablement.ts:103); a new test pins a disable landing while an enabled root scan is still pending.
Host install moved to the shared boot path. installChildSessionSearchService now runs in initializeMainProcessRuntime, which desktop and headless serve both reach, instead of the window-only registerCoreHandlers (main-process-runtime-service.ts:137). registerCoreHandlers is only invoked by main-window-core-services.ts, so no host loses the service and headless serve gains it; the host-registration test asserts the new location.

^{｜ View workflow run ｜ Using DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏}

pullfrog

ℹ️ No critical issues — one design observation inline plus a stale-comment nit.

Reviewed changes

Delta since the prior pullfrog review (705a35a): commit 100d542 replaces the desktop's parent-side 5-minute scan-root poll with a child-initiated root request, and refreshes roots only on full sweeps.

Child-initiated root refresh. resolveRoots?: (signal) => Promise<roots> added to the indexer options; SessionSearchIndexer keeps a mutable this.roots, refreshed only on a full pass and reused by recent cycles (session-search-indexer.ts:279). A failed resolve rethrows, re-arms sweepNext, and deliberately does not sweep stale roots.
Request/response over the scanner-service protocol. New session-scanner-service-root-request.ts sends {type:'sessionSearchRoots', id} and awaits a matching answer; the parent answers in AiVaultScannerServiceClient.onMessage from a new resolveSessionSearchRoots option (= localAiVaultScanRoots), guarded by child identity and connected. Both message unions and isAiVaultServiceChildMessage gained the type.
Static init roots. session-search-service-init.ts no longer re-resolves; it emits roots:{executionHostId}. SessionScannerServiceSearch gains a constructor resolveRoots, and its sameSessionSearchRoots rebuild branch is now reachable only from callers that push real roots.
In-process hosts. orcad passes resolveRoots: localAiVaultScanRoots (roots resolved lazily on first full sweep); the relay still registers without one.
Reconcile semantics. createSessionSearchService.reconcile now requests { full: true }; sendAiVaultServiceCall extracted from the private sendCall; historyDays normalization deduped into the shared settings module.

ℹ️ Nitpicks

src/main/ai-vault/session-scanner-service-search.ts:47 — the comment still says "the parent re-resolves them on every push"; this commit removed that (sessionSearchServiceInit returns a constant host id), so the rebuild branch is now only meaningful for callers that pass real roots. Worth rewording so the next reader does not look for the deleted push.

^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏}

pullfrog · 2026-09-14T04:13:14Z

 }): SessionSearchService {
  return {
-    reconcile: () => indexer.reconcile({ full: false }),
+    reconcile: () => indexer.reconcile({ full: true }),


SessionSearchService.reconcile is only reached from the registry's freshness: 'wait-until-current' path (reconcileWithin, 5 s budget), so mapping it to a full sweep now makes every fresh search kick off a whole-machine sweep plus an IPC round-trip for root discovery. Because the child runs searchReconcile and searchSessions on the same interactive lane, the search that follows queues behind that sweep. The pass deadline bounds it (~5 s) and warm sweeps are cheap, so this is not broken — but it does couple a client freshness hint to the heaviest pass. Worth confirming the coupling is intended, or noting that the indexer's scheduled sweep (every 15 cycles) already covers root refresh.

Technical details

# Freshness search now triggers a full sweep ## Affected sites - `src/main/ai-vault-search/session-search-service.ts:24` — `reconcile` changed from `{ full: false }` to `{ full: true }`. - `src/main/ai-vault-search/session-search-service-registry.ts:62-76` — `reconcileWithin` is the only caller; it races `reconcile()` against a 5 s timer on `freshness: 'wait-until-current'`. - `src/main/ai-vault/session-scanner-service-search.ts:78-81` — `searchReconcile` awaits `instance.reconcile()` on the interactive lane that `searchSessions` shares, so the racing search still waits out the sweep. - `src/main/ai-vault-search/session-search-indexer.ts:279-285` — the full sweep additionally awaits a parent IPC round-trip for root discovery. ## Required outcome - Confirm a client freshness hint should own a whole-machine sweep, or give root refresh a lighter trigger (e.g. keep reconcile recent-only and rely on the scheduled sweep) so the freshness path does not depend on the heaviest pass.

* fix: gate startup agent recovery on host inventory * fix: defer recovery while a live agent lacks conversation ownership * fix(mobile): two known main bugs the RPC migration preserved (#20563) * fix(mobile): two known main bugs the RPC migration preserved A malformed host `error` and a null settings result both reach a property read that throws. Both are deliberate behaviour changes; the goldens move in the follow-up commit. `hostReplyErrorTextOrFallback` passed a truthy non-string through under a `string` annotation. Its one caller is the in-band `git.commit` failure, and every consumer of that text is display or prompt copy: `use-mobile-create-pr-runner` and `PrSidebarCreateEmptyState` record it as a commit failure, `use-mobile-commit-failure-recovery` hands it to `summarizeCommitFailure`, which starts with `raw.slice(...).replace(...)`. So no consumer needs the value, and the decision is the fallback rather than `String(value)` — the relay handler declares `commit(): Promise<{ success: boolean; error?: string }>`, so a non-string is a malformed reply, and `generatedCommitMessageReader` in the same domain already reads a non-string host error as absent. The parameter stays `unknown`, which it honestly is, and the `SAFETY` cast is gone. `useNewWorkspaceRuntimeContext` read settings through `settingsRead`, whose reader preserves main's `boxed!.settings` throw, so a `null` or absent result threw a TypeError out of the effect — losing the trusted-hooks publish and the available-provider computation that follow it, not just the settings. It now uses `optionalSettingsRead`, the operation that already reads a null or absent result as absent settings, so the reply degrades exactly the way a reply with no `settings` member does. Reply-side only: same method, same params, same barrier, no wire change. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): re-record the goldens the two bug fixes move Baseline bumped to 3f71999237. Two goldens move an observation; the other 151 move only `baseline` and `recorderSha256`, which `pilot-scenarios.json` is still digested into. Observation moves, one claim each: - `matrix-hostedreview.create-intent-git.commit-1`, partition `inner-false-object-error`: `settlements.run.value.error` and `state.outcome.error` go from `{"message":"inner refused"}` to `"Commit failed"`. A non-string in-band `git.commit` error is a malformed reply and now reads as the screen's copy, converging with `result-absent`, `result-null` and `outer-refused-no-message`, which already reported the fallback. The other ten partitions at this site are unchanged. - `matrix-settings.workspace-context-settings.get-1`, partitions `result-null` and `result-absent`: the `unhandled-rejection` TypeError effect (`reading 'settings'`) is gone and `state.providers` goes from `[]` to `["github"]`. The effect no longer aborts the rest of the hook, so the provider computation runs; `state.settings` stays null because nothing was published, which is how a reply with no `settings` member already degraded. The other nine partitions are unchanged. Header-only moves: - 9 goldens of the `settings.workspace-context` family rename `namedDeltas` from `new-workspace-runtime-context-null-settings-typeerror` — the name now lies, the TypeError is fixed — to `new-workspace-runtime-context-null-settings-degrades-to-absent`. - All 153 move `baseline` and `recorderSha256`. The digest covers `pilot-scenarios.json`, so the baseline bump and the rename re-digest every file. No sender recording moved: both fixes are reply-side, and no golden's `sender` or `payloads` field differs. The README paragraph that claimed the settings TypeError was preserved is updated, and now records that the `ui.get` leg of the same hook still is. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * fix(mobile): degrade a null ui.get result the way the settings leg now does One host answers both legs of useNewWorkspaceRuntimeContext, so fixing only settings.get left the likelier failure in place: a null or absent ui.get result still threw `reading 'ui'` out of the effect, skipping the provider commit. Review follow-ups on the same files: reply() returns the literal uncast and the stub client is FakeSession, dropping two assertions and their SAFETY disables; the degradation cases now assert absolute state instead of comparing mounts. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): re-record the goldens the ui.get leg fix moves Observational move, 1 golden: - matrix-settings.workspace-context-ui.get-1: the `result-absent` and `result-null` partitions drop their `reading 'ui'` unhandled-rejection effect and their state commits `providers: ["github"]` instead of `[]`, because the effect no longer throws before the provider commit. Header-only moves, 153 goldens: `baseline` to the fix commit and `recorderSha256`, which covers `pilot-scenarios.json` and so re-digests on the delta rename. The delta is renamed `new-workspace-runtime-context-null-settings-degrades-to-absent` -> `new-workspace-runtime-context-null-results-degrade-to-absent` (9 goldens): it now covers both reads, not just settings. README updated to match. No sender recording moved: resolving the value pool across all 153 goldens shows `sender` and `payloads` byte-identical everywhere. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * refactor(mobile): name the ui.get result shape so the changed cast carries a rationale The inline union wrapped over four lines and tripped the changed-code casting gate as a new assertion; a named alias keeps the cast on one line under a SAFETY note. No behaviour change. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): repin the golden baseline to the cast-rationale commit Header-only: `baseline` on all 153 goldens. The re-record is inert — no golden moves observationally and no field other than `baseline` changes. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): pin the ui.get trust blank, and correct two stale acceptance comments The goldens cannot catch a regression to `if (uiResult?.result)`: the scenario's success reply is `{"ui":{}}`, so every partition of matrix-settings.workspace-context-ui.get-1 records the same `trust:{}` state. The new case answers once with real trust and again with a null result on a fresh client, which is the only shape where skipping the blank is observable — trustedOrcaHooks gates the setup-hook approval prompt in use-new-workspace-create-submit.ts, so a stale value would skip it. settingsRead's comment still claimed workspace context, which this branch moved to optionalSettingsRead; both comments now name their real callers. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): repin the golden baseline to the trust-blank commit The record fence rejected the previous pin ("Product sources or lockfile differ from the pinned main baseline"), so the branch was no longer re-recordable. Header-only: `baseline` and `recorderSha256` on all 153 goldens — the digest covers pilot-scenarios.json, whose only edit is that baseline. The re-record is inert: 0 goldens move observationally and no other field changes. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * docs(mobile): name the right operation per refuse-after-data probe Three of the five probes read through optionalSettingsRead, not settingsRead: repo metadata and resume metadata already did, and workspace context does as of this branch. The sentence now splits them and states why the split does not move what the probes record. Markdown is excluded from recorderSha256, so no re-record. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): pin the recorder's unhandled-rejection capture This branch removed the last two goldens that recorded an unhandled-rejection effect, so nothing exercised unhandled-recording.ts any more: gutting the emit to `void captureError(error)` leaves all 153 goldens comparing clean. The unit test drives a detached rejection through the window and asserts both the effect and the listener restore. README says so where it describes the capture. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): re-digest the goldens for the new recorder test Header-only: `recorderSha256` on all 153 goldens, which covers every non-markdown file under rpc-recording/ and so moves for the added test file. The re-record is inert: 0 goldens move observationally and no other field changes. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): pin each RPC golden to its own scenario input, not the whole manifest (#20562) * refactor(mobile): pin each golden to its own scenario input, not the whole manifest `recorderSha256` covered the recorder directory plus `pilot-scenarios.json`, so every golden's header was a function of every other family's scenarios. Adding a family for one domain re-digested all 153 goldens and put a conflict on that line in every domain branch in flight, which serialized the step-4 fan-out. Split the two things it conflated. `recorderSha256` now covers the recorder directory only, with unchanged semantics: a recorder edit still forces a full, deliberate re-record. A new `scenarioSha256` pins the scenario input that golden was recorded from — every scenario `runRecording` consumed for it, in order — canonicalised through `captureValue` so an explicit-undefined param stays distinct from an absent one. `goldenRecording` takes that list instead of just its first member. The variants are hashed rather than the base they expand from because they are what was recorded: a matrix site, its replayed normal result and its partition replies are all visible in them without the derivation having to be restated. `derived-goldens.ts` is that derivation, extracted from `family-recordings.test.ts` so the digest and the recording agree by construction — a property test that restated how a matrix or schedule expands could agree with itself and with nothing else. It reproduces exactly the 153 golden ids on disk, and the census the suite already ran (every family matrixed, no stale normal-result inventory entry) now reads off its output. `golden-header-digest.test.ts` pins the four properties: - a new family in the manifest moves zero existing goldens' headers, and derives two of its own - editing one field of `b1` moves exactly `b1` and its family's four matrix goldens — not the two other `legacy-inventory` scenarios, and not the goldens that expand from `inventory-lifecycle` - editing a recorder file still moves every golden's `recorderSha256`, and no `scenarioSha256` - `recorderSha256` is unchanged by the manifest's contents, and no longer reads the file at all `GOLDEN_FORMAT_VERSION` goes to 4: a version-3 header has no `scenarioSha256`, and `compareGolden` walks the expected header's keys, so a reader that accepted one would compare that golden's own scenarios as though they were unpinned. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): re-record the 153 RPC goldens for the split digest Recorder edit, so every golden needs rewriting. Recorded from the pinned baseline `16d1ab81d3` with this branch's recorder overlaid, per the README's procedure: main has moved past the baseline, so recording in place would have failed the product-source fence. Three header fields moved and nothing else did: - `recorderSha256` 6a12160a87… -> 2fda557f58…, one value across all 153 files - `scenarioSha256` added, 153 distinct values - `goldenFormatVersion` 3 -> 4 No observation, checkpoint, value-pool entry, `baseline`, `lockfileSha256` or `platform` changed: git diff -U0 -- mobile/rpc-foundation | grep -E '^[+-]' | grep -vE '^(\+\+\+|---)' \ | grep -vcE 'recorderSha256|scenarioSha256|goldenFormatVersion' 0 Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * refactor(mobile): certify the pilot goldens from the derivation that digests them `pilot-recordings.test.ts` restated `[scenario]` instead of consuming `pilotGoldens`, so the claim that a golden's `scenarioSha256` is a function of the same derivation that records the file held only for the 75 family goldens: dropping a scenario from `pilotGoldens` left the whole suite green and put that golden outside the header oracle. The pilot suite now iterates `pilotGoldens`, and a census fails if the derivation and the goldens directory disagree in either direction — which also closes the pre-existing orphan-golden gap. Also from review: pin the cross-sibling replay that hashing the generated variants buys (a matrix golden's `normal` partition replays a sibling's recorded reply, so editing that sibling must move it); state the real reason for the format bump, which is the diagnosis a version check gives rather than a rejection the byte compare already made; drop the fourth property test, which re-proved what tests 1 and 2 and `recording-runner`'s digest test already fail on; and drop a guard in `scenarioSha256` that its only caller reaches after an identical one. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): re-record the 153 RPC goldens for the review edits Recorder files changed, so `recorderSha256` moved. Recorded from the pinned baseline with this branch's recorder laid over it, per the README's migration-branch procedure. That one header field is the only line that moved in all 153 files: `scenarioSha256` and `goldenFormatVersion` are unchanged, and no observation moved. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * docs(mobile): correct the recording suite's test count Round-2 review: the README said 200 tests; the suite is 209 after the five added here. Markdown is outside recorderSha256, so no golden moves. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): re-record the 153 goldens on the merged baseline Four header fields moved and nothing else. Proven against origin/main: every changed line in all 153 files is one of these, and the file set is unchanged. - `recorderSha256` 70aa6f59e0 -> 58a461dbc9: this branch's recorder, and it now digests only the recorder directory, not the scenario manifest. - `scenarioSha256` added, 153 distinct values over 153 goldens. - `goldenFormatVersion` 3 -> 4 for that added field. - `baseline` 5ec0b2698f -> e53f1557e1, the merge's repoint onto the real main commit. #20563's value was a branch commit the squash left unreachable, so the record fence's `git diff <baseline>` could not resolve it. No checkpoint, value pool, effect or settlement byte moved, so main's recorded behaviour is carried over intact. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * docs(mobile): account for main's added recorder test in the suite count The merge brought in `unhandled-recording.test.ts`, one test, so the recording suite is 210 rather than the 209 this branch documented. Markdown is excluded from `recorderSha256`, so no golden moves. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * fix(native-chat): stop a bounded tail read from moving the chat cursor past unapplied rows (#20581) * fix(native-chat): stop a bounded tail read from moving the chat cursor past unapplied rows A structured chat pane could latch "Working for N" forever after the agent had finished, showing the send arrow rather than Stop, while the sidebar and `worktree ps` correctly read idle. The client replica has one position (`state.cursor`) and one body. Two operations keep those consistent: replace (both from one host snapshot) and append (rows contiguous with the cursor). The `tail-page` branch was a third thing: it took the cursor from the journal head, the items from a bounded page (200 items, byte-capped), then merged retained client submissions over the page's. Under continuous journal writes the client is always slightly behind, so the branch ran on every window focus and on every pane re-activation. When more than a page of rows had landed since a send, that send's user item fell off the page, its submission was not carried, the retained `pending` survived, and the cursor jumped past the dispatch-acceptance row. Nothing re-sends it: a batch carries only touched items and that submission is never touched again. Delete the third operation rather than guard it. A live subscription is now the only thing that moves the cursor, and `subscribe({ cursor })` already replays exactly the missed rows. - remove the window `focus` listener and the owner/transport `refresh` contract - skip warm hydration: a retained owner subscribes at its applied cursor - cold hydration keeps its history read, applied as the existing `snapshot` (replace) event rather than `tail-page` - delete the `tail-page` action and its reducer branch - delete `resumeCursor` and `shouldAdvanceStructuredResumeCursor`; two cursors with two advancement rules were how position and body drifted apart `older-page`/`loadOlder`, the unattached-refusal grace, generation guards and the coalescer are unchanged. No host, wire or schema change. Also fixes a second cost of the same branch: focus during a busy turn discarded paged-in older items, shrinking the transcript to one bounded page mid-turn. * fix(native-chat): preserve unavailable mixed-version session fences * refactor(mobile): send the task workspace-creation domain through typed RpcOperations (#20568) * test(mobile): record main's task workspace-creation RPC behaviour before migrating it 28 scenarios over nine task senders, recorded from main so the step-4 migration of the workspace-creation half of src/tasks/ has a frozen answer to compare against. Four senders mount as plain exported functions; three are model-chained hooks mounted the way the settings adapters mount theirs. The 153 existing goldens change header-only (`baseline`, `recorderSha256`): any new scenario re-digests the recorder, and the pinned baseline had drifted from main because the source-control migration landed. Content is byte-identical on all 153 — verified field-by-field against HEAD. `operation-module-loader.ts` now shares src/transport/rpc-delivery-ambiguity.ts with mounted modules instead of evaluating a second copy. The mark is a WeakSet keyed on the rejection object, so the copy the loader built had an empty registry and every delivery-unknown rejection read as a definite failure inside the operation under test — worktree.create's whole replay path was unreachable. With one registry, `tw-create-retry-ambiguous-after-drop` records the create still pending at the reconnect wait and abandoning at exactly 20000 ms, while the unstamped-create scenario records the same rejection surfacing at 0 ms. No existing golden moves: no other mounted module consumes the mark. `task-preferences-optimistic` is re-anchored above the send rather than across it, so migrating this file does not have to move the anchor. It still kills, and for the same reason: the preset the screen shows no longer follows the tap. Scenarios deliberately pin the empty-message refusals (`*-refused-empty-message`, `*-empty-message`), because a refusal with no message falls back to the screen's copy while a transport error with no message does not, and the two paths are easy to collapse when a call site moves behind an acceptance policy. Goldens: 153 -> 201, 2.9M -> 3.7M. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): format the recording manifest and re-digest the goldens `oxfmt --check` from mobile/ collapses a one-element `sites` array in each new scenario. The JSON value is unchanged — verified by comparing both files parsed and key-sorted — but the manifest is inside `recorderSha256`, so all 201 goldens carry a new digest. Every other field, header and observation alike, is byte-identical. Re-recorded in a separate worktree at the previous commit so the goldens stay attributable to main's product source rather than to the migration that follows. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): separate the goldens from the migration, and re-digest The previous commit accidentally carried the product migration alongside the manifest format, which both broke the commit that is supposed to prove parity and left the suite red: the digest was recorded without a comment move that a lint fix had made inside the adapter, so all 201 goldens failed their `recorderSha256` header. This backs the product half straight out again — the next commit re-applies it byte-for-byte — and re-records from the pinned baseline in a separate worktree carrying this branch's recorder, per the procedure in the recording README. Every field except `recorderSha256` is byte-identical to the previous commit's goldens on all 201 files, so no observation moved in either direction. The suite is green here with main's product source, which is what makes the next commit's "no golden changed" claim mean something. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * refactor(mobile): send the task workspace-creation domain through typed RpcOperations 12 of src/tasks/'s 37 raw-port files now send through a declared operation instead of the raw request port: 36 references to 0, leaving 25 files and 73 references for the provider item/detail/mutation half. No golden moved — `git show --stat` on this commit touches nothing under mobile/rpc-foundation/, which is the parity claim. Twenty-two operations over twenty methods, in four modules named for what they send: workspace create (create, PR/MR base resolution, create-time capabilities), workspace source (SSH connect/state, agent detection, repo hooks, sparse presets, ref search), task runtime (status, ui.get/ui.set, preflight, Linear status, settings.update) and the Smart picker's provider reads. Two methods carry two policies each, and both pairs are named. `status.get`: the Tasks screen cannot hydrate without it and surfaces the host's message, while create-time capability probing degrades to "no capabilities" and creates anyway — so one throws on refusal and one skips. `ui.set`: two sites await it, one is fire-and-forget and never interprets the reply at all. Both pairs share one reader, so no method has two readers. No new acceptance policy. worktree.create keeps its delivery-unknown contract. `request` returns the transport promise itself, so the retry loop catches the object the transport marked; two new tests assert `toBe(marked)` in one direction and that an unmarked rejection stays unmarked in the other, because a mark added on the way out would replay a create the host never received. `tw-create-retry-ambiguous-after-drop` records the create still pending at the reconnect wait and abandoning at exactly 20000 ms. Three sites still read the raw refusal envelope before interpreting, because the code or the message decides the route and no acceptance policy carries either through: the create retry needs the message for `isRetryableWorktreeCreateConflict`, and the paste lookup needs `method_not_found` to retire the slug probe host-wide. Both are documented at the site. The hydration barrier keeps raw requests inside its `Promise.all`. main's group rejects as soon as one leg rejects; `startRpcOperation` + `interpretAtRpcBarrier` would wait for the slowest peer and let a later policy surface a different error. Interpretation stays after the `stale` guard, where it was. `WorkspaceCreateParams` is now `RpcSendParams<'worktree.create'>` rather than `Record<string, unknown>`, which types the builder and the operation together; every field the three builders already sent typechecks against the host schema unchanged. `RpcSendArguments` now also makes params optional for a method whose params type has no required field, because `preflight.check` is such a method and main sent it none — requiring `{}` would have put a new object on the wire. The Mobile Tasks source-parity hashes move for the same reason bound settings requests moved them: the method string and the envelope read leave the screen. The signature diff is evidence rather than a re-pin — `semantics` is a pure deletion of 22 `rpc:` call signatures and 22 method literals with nothing added, statement/declaration/render/style counts are unchanged, and render tokens, styles and declarations are byte-identical. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): split the task workspace adapters at the sender/hook seam The single adapter file reached 344 lines against mobile's 300-line limit. CI lints every file, so this is red there even though the changed-code gate does not report it. Split along the seam the recording README already draws: exported async senders that take a client and need no React host, and the drawer's three model-chained hooks. No adapter body changed. Both files are inside `recorderSha256`, so all 201 goldens carry a new digest. Every other field is byte-identical, verified file by file. Re-recorded from the pinned baseline in a separate worktree carrying this branch's recorder, so the goldens stay attributable to main's product source. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * refactor(mobile): give the one-key unchecked reader a name Four readers were the same three lines: read one property off the reply, wrap it unchecked. `rpcUncheckedMemberReader` is the one-key sibling of the existing `rpcUncheckedPayloadReader`, so the annotation and the closure go away at each site. The pilot's `commitCompareEntriesReader` is converted too, so the helper has no longhand twin left to copy from. No behaviour change: the helper composes the same `rpcReadUnchecked` over `rpcPayloadMember`, including the property-read exception on a null result. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): record the local arm of workspace agent detection `preflight.detectAgents` was the one migrated operation with no recorded coverage: the ssh adapter hardcoded `connectionId: 'ssh-1'`, so the detection effect's ternary only ever took the remote arm and the local call site could be repointed at another method without a golden noticing. The adapter now takes the connectionId as a parameter and registers twice; `tasks.workspace-ssh-local` mounts the same hook with no connection, which is the only difference the effect branches on. Recorded at the pinned baseline with this branch's recorder laid over it, so the new golden is main's behaviour and the migrated code has to reproduce it — it does. Goldens: two added (`tw-workspace-ssh-local-agents` and its reply matrix). The other 201 changed on `recorderSha256` only, because the adapter edit moves the recorder digest every golden pins. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): drive workspace create and the Linear list to a recorded wire Two operations passed a policy swap unnoticed, both because no golden reached their acceptance branch. `worktree.create`: the create hook's fixture resolved setup to a prompt, so all three settings.task-workspace scenarios stopped before the request and the only consumer that hands a refusal to interpret was never recorded. The adapter now takes the setup resolution as a parameter and registers a second family that resolves it, so createWorkspace runs to the wire. Two scenarios: a Linear item that creates directly, and a GitHub pull request that resolves its base first, which also puts this hook's built params — start point, generated display name, agent launch fields — in a golden for the first time. The existing prompt family is untouched, so its recordings still pin that branch. `linear.listIssues`: it appeared only in a non-base scenario, and the matrix reads the family base, so the family had no partition for it. The base now lists assigned issues after searching. Goldens: five added. Five moved beyond the digest, all derived from the smart-search base that gained the list leg. The other 198 changed on `recorderSha256` only. Recorded at the pinned baseline with this branch's recorder laid over it, so every new golden is main's behaviour. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): drop the unreachable unmount branches from the task adapters Nothing dispatches `unmount` to these three adapters: the only producer is `lifecycleSchedules`, driven from a hardcoded five-id list that names no task-workspace family, and it pushes a `remount` right after, which these adapters would throw on. The branch read as lifecycle coverage that was never wired up. `dispose: hook.unmount` already tears the mount down. Goldens re-recorded at the pinned baseline because the recorder digest moved; `recorderSha256` is the only line that changed in all 208. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): re-record the goldens at main's post-squash baseline Recorded from a detached checkout of e53f1557e1 (main's unmigrated product code) with this branch's recorder laid over it, so the parity claim stays non-circular. - `baseline` repinned to e53f1557e1 on all 208 goldens; main pinned 5ec0b2698f, a pre-squash branch commit not reachable from main. - `recorderSha256` moved on all 208 because this branch's adapters are in the whole-manifest digest. - 55 task-workspace goldens re-recorded at the new baseline. - No other line in any of main's 153 goldens changed. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): re-record the goldens under #20562's per-scenario digest Baseline repinned to 50e752fc66 and all 208 goldens recorded from that commit's unmigrated product tree with this branch's recorder laid over it. recorderSha256 moves on every golden because the task-workspace adapters live in the recorder directory. scenarioSha256 does not move on any of main's 153: the manifest only adds 31 scenarios and edits none, which is the property #20562 was built to give. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * feat(ai-vault-search): construct the session search indexer in the scanner service behind a setting (#20516) * feat(ai-vault-search): persist agent-session search consent and retention Two booleans and nothing else: `enabled` and `historyDays`, off by default because building the index reads every transcript on the machine. No `paused` -- the PR 3 indexer is immutable, so every change is close-and-construct. The settings IPC normalizes a write like every other field and hands the change to the index; there is no UI for it until PR 8. * feat(ai-vault-search): hold one indexer and engine pair per host The object that owns a host's live index and the three recipes that change it. The indexer is immutable, so a settings change is close-and-construct, disabling is close with no replacement, and clearing is close, remove the database, construct. The new instance's first sweep purges a narrowed window and admits a widened one, so neither needs a code path. The database sits beside the scanner's parse cache, one file per host. A runtime with no node:sqlite can hold no index at all, which the Node 18 floor on orcad and the relay makes a real case rather than a hypothetical one. * feat(ai-vault): let the scanner child own the session search index The transcript reader runs in that child, so the index consumer has to as well: one read serves both the session list and the index. Three request operations (search, status, reconcile) and one fire-and-forget settings message carry everything a parent needs; main never opens the database file. The init frame becomes a factory because it is read at every spawn, so a respawned child sees current consent rather than the first frame's. A child holding a running index is never idle from the parent's side, so idle retirement is suppressed while the index is on -- retiring it would stop the reconcile loop until some later scan happened to respawn one. Both files this lands in were already at the max-lines ceiling, so three collaborators move to where they belong rather than being disabled around: the invalidation deadline into the class that owns invalidations, call cancellation and the start requeue into the call-state module, and orcad's flag parsing into its own file. * feat(ai-vault-search): register a search service on every host that answers Without a registered service a host answers no-service, which means "this host does not have the feature" rather than "the index is off". All three hosts now answer the second thing. The desktop forwards to the scanner child. orcad and the SSH relay daemon have no such child -- orcad ships only the watcher and daemon entries, and the relay's AI Vault sidecar runs the remote scanner, which publishes nothing to the transcript channel -- so on those two the index lives in the process that would drive its reads, gated on a runtime that has node:sqlite at all. The relay registers with consent off and no way to turn it on: nothing carries a setting to a remote host yet. That is the honest state, and it is still worth registering, because it is what tells a client the difference between off and too old. * test(ai-vault-search): price a warm pass over five thousand transcripts The number the reconcile interval will be revisited against, measured rather than argued: a warm sweep stats every file under every root, a warm cycle stats the newest N per agent, and neither reads what the index already holds. It does not tune the interval. * fix(ai-vault-search): answer the casting gate without assertions main's new type-assertion rule reaches every file this branch touches. All nine sites drop the cast rather than carry a SAFETY: rationale: the operation guard narrows with `in`, the sqlite probe narrows the builtin it loads, the child test keeps the discriminated reply instead of widening it, and the settings resolver takes `unknown` -- which is what it really reads, since a persisted profile can hold a value no version of this code wrote. * fix(ai-vault-search): let a refreshed scan root reach the live index The parent re-resolves scan roots before every policy push, precisely so a WSL distro or extra Codex home that appeared since the child spawned enters the window. The child forwarded only the settings to a live instance and used the roots solely in its `??=` initializer, so those roots were dropped for the child's lifetime. The indexer stays immutable: a structurally different root set closes the pair and constructs a new one, the same way a changed databasePath already does. Compare via `sameSessionSearchRoots` rather than a plain JSON compare, because nothing fixes the key order two producers write; lists are sorted too, since the indexer walks every root and a re-enumeration that reorders is not a change. An unchanged set still never restarts a running index. The orcad and relay in-process hosts resolve roots once at install and never re-apply, so they have no such seam. * fix(ai-vault): restart the scanner child the index is holding Three review items. The hold keeps a child alive for the index, but only a queued call ever started one: `pump()` skipped a hold with an empty queue, so an idle indexing child that crashed, or an `ensureChild()` that failed at start, left indexing stopped until an unrelated request happened to arrive. `pump()` now starts the child the hold requires, which is also the restart callback the fault policy already schedules, so the existing delay and circuit bound the retry exactly as they bound a queued call's start. `updateSessionSearch` goes through the same seam instead of its own `ensureChild` call. A search registers no AbortController, so a cancel sent for a search id was added to the `cancelled` set and never consumed. Nothing can reach that today -- no caller passes a signal and the child answers in milliseconds -- so this is only a leak of ids: consume it when the search settles. The orcad argument doc claimed a `--`-prefixed value stays a flag. The parser takes the next token regardless, and orcad-launch-contract.test.ts pins that, so the doc is what was wrong. Behaviour is unchanged. * fix(ai-vault): recover search indexing and refresh scan roots * fix(ai-vault): defer search refresh policy reads * fix(session-search): stabilize paging and host enablement * fix(session-search): refresh host roots within full sweeps * docs(session-search): clarify initial root fallback * fix(native-chat): hide activity while awaiting input (#20496) * fix(native-chat): hide activity while awaiting input * fix(native-chat): keep approval turns cancellable * test(native-chat): satisfy split PR quality gate * fix(native-chat): catalog approval cancellation label * fix(native-chat): include approval cancellation runtime label * fix(codex): settle prompts when cancelled turns complete * fix(codex): settle prompt registry fallbacks * test(native-chat): cover pending interaction fallbacks * test(native-chat): split prompt state coverage * test(native-chat): keep prompt state isolated * fix(native-chat): bound prompt turn backfill * refactor(codex): centralize prompt registry bounds --------- Co-authored-by: Merge Sim <sim@local> * Update README downloads badge * Bump mobile app.json to 0.0.50 (#20661) * fix(native-chat): bound a dispatch reason before it reaches the journal row (#20654) `AgentJournalSubmission.reason` was the only unbounded field written by Orca's own code. `dispatchSafely` sets it from the adapter's raw `error.message` and `journalDispatchRowBuilder` stored it verbatim, so a provider error carrying a multi-megabyte body -- a stringified HTTP error payload, say -- reached the row at whatever length the provider sent, and stayed on disk at that size for the life of the journal. It now goes through `boundInlineText` with the journal's existing inline limit, the same idiom already applied to arbitrary text on the Claude and Codex translation paths. The bound must stay head-preserving. `dispatchRejectionWasTransportWriteFailure` prefix-matches the value, and `dispatchRejectionReasonIsInternal` builds on it, so a bound that kept the tail instead would stop classifying a clipped transport failure and render raw provider text to the user as an ordinary rejection notice. A test pins that, and clipping stays marked rather than silent so a truncated reason is never presented as the provider's complete explanation. Rows written before this keep their full text, so readers can still meet an unbounded reason. * fix(native-chat): keep a resumed transcript pinned to its end (#20651) * fix(native-chat): keep a resumed transcript pinned to its end Follow state was recomputed from distance on every scroll event, and a pin writes scrollTop itself, so the browser reports that write back as a scroll event a frame later. Once a resumed session's later history pages and settling row heights had moved the end away from it, that echoed event read as the reader leaving and the pin was dropped for good, stranding them mid-transcript. Measured in Chromium: a pin followed by same-task growth delivers a scroll event reading 2000px from the bottom, indistinguishable from a reader scrolling up. Pins now go through the virtualizer instead of writing scrollTop directly, so both parties resolve the end through the same maximum rather than holding rival definitions of it. Whether the reader left is now a question of provenance rather than distance: an offset this transcript wrote is never a departure. The end test reads live geometry, because the virtualizer's own isAtEnd subtracts a cached offset from a live maximum and this handler runs before that cache is refreshed. overflow-anchor:none stops the engine moving scrollTop under a settling row, which would otherwise look like the reader. This does not make ownership singular. The virtualizer still writes autonomously from several paths and those writes stay unattributed; what this removes is the rival definition of the end, not the second writer. * fix(native-chat): cancel stale end reconciliation * fix(native-chat): attribute scroll ownership centrally * Surface stage, unstage and discard failures with retry capability (#20423) * fix(source-control): surface stage, unstage and discard failures * fix(source-control): use single slot for entry failure toasts - Consolidate entry failures to one stable slot instead of per-worktree - Handle stale retries inline at click time rather than via a cleanup hook - Remove retry button from discard failures to prevent destructive accidents * test: improve type safety and mock patterns in source-control tests - Add proper type definitions for toast options and test data instead of using `as never` - Replace `mock.calls.at(-1)` with safer `mock.lastCall` pattern - Create `entry()` helper to construct typed test entries - Add explicit type annotations to mocked functions for better IDE support * test: extract shared toast options type for source control tests Consolidate duplicate `ToastOptions` type definitions across three test files into a single `SourceControlToastTestOptions` type, reducing duplication and improving consistency. * fix(source-control): separate refresh failures from mutation failures Post-mutation refresh failures are logged separately, not surfaced as toasts (mutation already succeeded). Use preventDefault() on retry to prevent sonner's auto-dismiss from swallowing re-raised failures. Consolidate stage/unstage into a shared handler to reduce duplication. * fix(source-control): only dismiss entry failures from the owning worktre Track which worktree owns the shared entry-failure toast slot. When a mutation completes, only dismiss the slot if the completing worktree is the one that raised the failure — a slow retry in one worktree should not erase a failure another worktree has since raised into the slot. * Remove entry mutation status refresh helper Inlined into the caller during consolidation of failure handling and tracking in the source-control entry mutations flow. * Simplify entry mutation refresh without wrapper Call refreshActiveGitStatusAfterMutation directly instead of through the refreshEntryMutationStatus helper. This ensures refresh failures propagate directly from the callback without being caught as mutation failures. Remove tests that validated the wrapper's error handling. * Add copy button to code blocks (#20357) * feat(native-chat): add copy button to code blocks Enable users to copy code snippets directly from chat messages via a dedicated copy button on fenced code blocks. Supports language detection and integrates with markdown rendering via a `renderCodeBlock` prop. * i18n: add English copy code button label * refactor: use React.isValidElement type parameters for type narrowing - Specify props types as type parameters to React.isValidElement instead of casting after the fact - Allows TypeScript to narrow element.props type automatically - Eliminates manual type assertions in extractCodeText and extractCodeFenceLanguage * fix(source-control): prevent text wrapping in section headers and action buttons (#20046) * fix(source-control): prevent text wrapping in section headers and action Use flex layout constraints (flex-1, shrink-0) and text truncation instead of wrapping to keep section labels and action buttons on a single line in the right sidebar. * test(source-control): add section action button alignment tests Ensure View all button stays on single line with icon actions in crowded section headers. Pin layout constraints (shrink-0, flex-wrap, whitespace-nowrap) to prevent regression. * Rely on Button base styles for action label wrapping Remove redundant shrink-0 and whitespace-nowrap utilities from section action buttons. These should be supplied by the Button component's base variant, not duplicated at each usage site. * fix(store): stop two no-op writes from re-running every selector in the app (#20641) * fix(store): stop two no-op writes from re-running every selector in the app zustand bails out of a `set` only when `Object.is(next, state)`. Two updaters that mean "nothing changed" hand it a fresh reference instead: - `setWorkspacePortScanRefreshing` wrote unconditionally — the one action in its file that did; its four siblings all early-return `state`. - `applyGitHubPRRefreshEvent` ended its no-op branch with `: {}`, and `Object.assign({}, state, {})` reproduces every field unchanged while still notifying. ~20 sibling sites in the same store already use `return state`. Both rebuild the root and wake every subscribed selector (~2.2k per the listener census). Renders are unaffected — the selection is unchanged — so the cost is wasted selector evaluation, not commit pressure. The resulting state looks identical either way, which is why it goes unnoticed; both tests therefore count subscriber notifications rather than asserting state. * test(store): use checked initial state in notification regression --------- Co-authored-by: m4air <m4air@Mac.localdomain> Co-authored-by: Neil <neil@stably.ai> * fix(ai-vault): bound streamed remote JSONL records (#20700) * fix(ci): stop hourly versions dropping below a tagged or already-shipped build (#20699) * fix(ci): stop hourly versions dropping below a tagged or already-shipped build Hourly/daily/adhoc based their X.Y.Z on GitHub releases, not git tags. When v1.4.202 was tagged and then its GitHub release vanished, the next hourlies shipped as 1.4.202-hourly — below both stable 1.4.202 and the 1.4.203-hourly builds already installed, so electron-updater stopped offering updates. Read main's v* tags and already-published channel tags instead. * docs(ci): record that 1.4.202's release was unpublished for a bug The leftover tag is what hourly must still honor; this was not a failed cut. * fix(store): preserve state identity for no-op updater branches (#20703) * fix(codex): settle a structured send on admission, and stop minting a colliding identity (#20138) * fix(codex): settle a structured send on admission, and stop minting a colliding identity Two sends could be written into the journal under one durable identity. Codex coalesces a mid-turn `turn/start` into the running turn rather than refusing it -- measured against real `codex app-server` builds 0.147.0, 0.150.1 and 0.153.4, none of which refuse and none of which fire a second `turn/started`. The dispatch path read the turn id from the turn/start response and stamped every accepted send `ordinal: 0`. Since a coalesced send gets the running turn's id back, two submissions persisted the same `providerItemId`. That string is durable, and it is the key a restore uses to match a submission against provider history, so the second message's real history row matched nothing and rendered as an extra bubble on replay. On 0.147.0 it is worse than a collision: the coalesced response returns a turn id that never starts and never completes, so the persisted key named a turn absent from history and NEITHER message could match. Identity is now minted from the echoed user message at `identityFor` -- the single point that mints the journal row's own identity -- so the settled key is by construction the one replay computes, rather than a parallel calculation that can drift. Dispatch returns `admitted` when the transport write completes; identity settles on the echo through a channel that did not previously exist for Codex. Waiters are keyed by client message id instead of being shifted off the front of an array by arrival order, and they are cleared on session close and child exit -- previously a timeout was the only thing that ever ended one. `TURN_ID_WAIT_MS` is deleted. It was never reachable on any build measured: `readCodexTurnId` returns non-null on all three, so the 10s wait never fired. The comment justifying it claimed older builds acknowledge before the id exists, which no tested build does. Three comments asserting Codex answers a mid-turn send with `turn already running` are corrected. Their only backing was a test fixture inventing that error string. The correction is factual only -- every changed line in `src/main/runtime/orchestration/` is a comment, and mid-turn delivery is still refused for both providers. Whether that policy is right is a separate question; it was resting on a false premise. Known gap, stated rather than implied: this prevents new collisions and does not repair journals already written with a colliding or phantom key. Those conversations keep duplicating on restore. Repairing them means re-matching persisted submissions against provider history and rewriting `providerItemId` -- which is what `journal-submission-reconciler.ts` is written for, and it still has no production caller. * test(codex): drop the synchronous-accept contract and the colliding `:0` from the integration fakes Three tests in the structured-session integration suites encoded the dispatch contract this branch replaces, and two of them pinned the defect it fixes. They asserted `agentSession.send` answers `dispatchState: 'accepted'` carrying `providerItemId: codex:<thread>:<turn>:0` at send time. That ordinal was never observed; it was stamped on every accepted send, which is exactly the collision this branch removes -- a send coalesced into a running turn is answered with the running turn's id, so two submissions persisted one durable key. The visible failure was a 30s timeout rather than a failed assertion. The fake client advertised no `agent-session.pending-send-result.v1`, and without it the host holds the reply until the send settles: a shim for clients too old to render a pending bubble. The fake provider then echoed the user message with no `clientId`, so nothing could correlate that echo back to the submission, and the wait ran to its own 30s ceiling. Real Codex sends `clientId` on that echo, and the fake now does too, which is what makes it a model of the provider rather than a sketch of one. The identity assertion is kept rather than dropped. Each send now asserts `pending` with no identity at admission, then asserts the submission settles `accepted` at `codex:<thread>:<turn>:0` once the echo lands. Same ordinal, but earned from `identityFor` on the echo -- the key a replay recomputes -- instead of guessed from the turn/start response. Ablated: removing `clientId` from the two echoes leaves both submissions `pending` and fails both assertions, so the assertion is load-bearing and not satisfied by something incidental. Both suites' client fixtures now advertise the capability set the desktop renderer sends in `src/main/ipc/runtime.ts`, which is what these suites mean by a client. The older-client settlement wait keeps its own coverage in `src/main/runtime/rpc/methods/structured-agent-session.test.ts`. `structured-agent-session-runtime-exit.test.ts` asserts `pending` for the same reason; it drives the host directly, so it never took the compatibility path, and what proves delivery there is still the turn the reacquired provider starts. The replay suite's "without dispatching it twice" property is untouched: one `turn/start` call, one replayed ledger row. * fix(codex): preserve unsettled dispatch correlations * test(codex): type the dispatch fixtures instead of asserting over them main's new casting gate (#20367 base) flags type assertions on changed lines. Replace them with checked types: the recording sink already satisfies its interface, both CodexSession fixtures are now annotated and carry real collaborators, the settlement assertion compares whole identities, and the integration helper reads submissions through the host's public journalSnapshot instead of its private session map. * fix(test): merge the duplicate doubt-reasons import the merge left behind Both sides added an import from journal-dispatch-doubt-reasons and the merge kept both statements, which the whole-repo native plugin gate refuses under --deny-warnings. * test(codex): a Fast mode turn is admitted, not accepted #20506 landed its Fast mode tests against the dispatch contract this branch replaces: a Codex send now returns admitted and settles its identity on the provider echo. The tier assertions the test exists for are untouched. --------- Co-authored-by: Merge Sim <sim@local> * test: add a verified OMP native-chat mock scenario (#20655) Co-authored-by: plotarmordev <plotarmordev@users.noreply.github.com> * fix(omp): preserve status after terminal title owner rewrite (#20610) Validated and independently reviewed OMP integration fix. Co-authored-by: shahidbeig-a11y <258701601+shahidbeig-a11y@users.noreply.github.com> * fix(omp): preserve zsh startup with global aliases (#20621) Validated and independently reviewed OMP integration fix. * fix(git): avoid Windows tree kills after the command has exited (#20606) Validated and independently reviewed OMP integration fix. * fix(terminal): retain renames before renderer pane hydration (#20619) * fix(terminal): retain renames before renderer pane hydration * test(terminal): keep late renames from recreating closed tabs * fix(agents): find OMP by its full project name (#20647) * fix(agents): find OMP by its full project name * test(agents): make picker baseline proof omit OMP aliases * style(test): brace picker baseline condition * feat(runtime): stream file uploads instead of buffering whole files (#16106) * feat(runtime): stream file uploads instead of buffering whole files Staging read each dropped file whole with readFile(), base64-encoded it (a 4/3 expansion), and passed the string through IPC to the renderer, which re-chunked it. Peak memory was ~2.3x the file size before a byte moved, so a 25 MB per-file cap existed to protect the heap. Staging now records identity only. The byte pump moves into main, where the file handle and the runtime socket both live: 384 KiB slices (512 KiB once base64-encoded, matching the chunk size the renderer used) appended through the existing files.writeBase64Chunk RPC. Peak memory is one slice regardless of file size, so the ceilings become user-safety limits on an unattended transfer — 2 GB per file, 8 GB per drop — and over-limit errors name both the size and the limit. Because staging and streaming are separate calls, the staged entry carries size, inode, device and mtime, and the streamer re-checks all four against the pre-open lstat and against the handle it actually reads. A source replaced or rewritten at the same size between the two calls is refused rather than uploaded under the original name. The post-read check compares mtime as well as size, so an in-place rewrite mid-transfer aborts before commitUpload renames anything into place. O_NOFOLLOW, realpath containment and stat identity are preserved, and the pairing revision plus the runtime id ride every chunk, so a re-pair or a replacement runtime aborts instead of appending the rest of the file to a different host. No wire change: files.writeBase64Chunk and its params are untouched, so old and new hosts behave identically. The SSH import path is separate and unchanged. The web client has no local filesystem to stream from and says so instead of failing obscurely. * fix(runtime): close the empty-upload and per-drop budget holes Two gaps the first pass left open. A zero-byte source returned before the post-transfer identity check, so a file that gained content during the empty write's round trip committed as an empty file at the user's chosen name. The empty chunk now falls through to the same final check the slice loop uses. Each staged source also started its own byte counter, so the 8 GB ceiling capped one source rather than the drop: five 2 GB files staged cleanly at 10 GB total. The IPC handler now carries one budget across sourcePaths and adds only what each source actually staged. The per-file ceiling is still re-enforced where the bytes move; the drop total holds at staging because identity enforcement means each file streams exactly the bytes measured. * docs(runtime): name the invariants the upload helpers carry * fix(runtime): name the source in errors and stop uploads with their window Three problems an independent review turned up. A dropped file's relative path is '', so the over-limit error read "'' is 3 GB, over the 2 GB per-file remote import limit" — the message this change exists to fix, naming nothing. Errors now fall back to the file's own name; the staged entry keeps '' so the destination path is unaffected. The streamer had the same shape, falling back to the hidden .orca-upload-<nonce> temp destination, a path the user never chose. The byte loop used to live in the renderer and died with it. Moving it into main meant closing or reloading the window left the rest of a multi-GB transfer running, with the renderer's temp cleanup never reaching its finally. An AbortSignal now rides the caller's lifetime and every chunk, is re-checked per slice, and main sweeps the abandoned temp path itself when the renderer is no longer there to do it. Upload failures also reached the import result wrapped in Electron's "Error invoking remote method '...'" prefix, because the throw crossed IPC instead of happening in-renderer; extractIpcErrorMessage unwraps it. An existing staging test asserted the empty-name message, so it encoded the bug rather than catching it; it now asserts the file name. * test(runtime): cover the containment check and the per-chunk host guards The "escapes the dropped root" test only reached the lstat symlink guard, so assertEntryInsideRoot had no coverage at all. The shape that actually needs it is a regular file under a symlinked intermediate directory: lstat sees a plain file, and realpath containment is the only thing that refuses it. Disabling the guard now fails this test and nothing else. Nothing asserted that the SSH target, connection generation and execution host reach the writeBase64Chunk params either — the renderer tests stop at the IPC boundary, so the streamer's half of that contract was untested. * fix(runtime): survive a straggling append when sweeping an aborted upload Aborting rejects the in-flight chunk locally, but the host may still apply that append, and appends open with flag 'a' — which recreates the file the sweep just deleted. The delete and the straggler also race: they are separate calls on a queue that is not ordered between them. Slices are strictly sequential, so at most one append can be outstanding. A second pass after it has had time to land is therefore sufficient, not merely a heuristic. The sweep moves out of filesystem-mutations.ts into its own module so the behaviour is testable directly. Found by an independent review pass, which also pointed out that the "escapes the dropped root" test only reached the lstat symlink guard. * fix(runtime): abort uploads only when the document commits, and honour manual disconnect per chunk did-start-navigation fires before will-navigate blocks an external link or a stray file drop, and the renderer survives those (verified against Electron 43 with a hidden window). Aborting there killed a healthy upload with a misleading 'window went away' error. did-navigate fires only once a new document has replaced the caller. The renderer's per-chunk calls used to go through the IPC handler that refuses a manually disconnected environment; the loop in main made no such check, so a disconnect mid-upload kept pushing the rest of the file. The handler now resolves the selector to an environment id and the streamer checks it per slice. Adds slice-boundary coverage against the real chunk schema and host write flags, staging-to-stream on a real filesystem, and handler-level lifetime tests. --------- Co-authored-by: Neil <neil@stably.ai> * fix(omp): preserve saved conversation names in session history (#20636) Co-authored-by: Brennan Benson <79079362+brennanb2025@users.noreply.github.com> * fix(ui): contain idle caret paint so agent panes stop burning CPU (#10554) An idle agent pane kept ~40% of a core busy just by being frontmost. The xterm cursor and the native chat caret blink with no paint-containment boundary, so Chromium treated each blink as damage to the whole pane ancestry and re-rasterized it twice a second. - `.xterm-container` and the native composer's input shell get `contain: paint`, bounding blink damage to the surface that blinks. - The mention hint gains `z-20` to match the slash picker: a contained element becomes a stacking context and paints at z-index 0 in tree order, which would otherwise cover the hint's drop shadow. Also records that DECSCUSR pins `decPrivateModes.cursorBlink`, which wins over the option in `_updateCursorBlink` — so parking `cursorBlink` does not reliably stop a hidden pane blinking. Pre-existing, documented only. Co-authored-by: Wooseong Kim <innocarpe@users.noreply.github.com> * feat(relay): expose preloaded PostgreSQL statement statistics (#20712) * fix(runtime): apply the tui-idle evidence ranking to mailbox delivery (#20578) fix(runtime): retry a delivery that the idle gate refused Gates delivery at the two points where each implementation commits to typing into the pane, rather than at each caller, and parks-and-re-offers a refusal so late idle evidence cannot strand a queued message. Refs #6011 * fix(agent-session): honour the backup-recovery fence floor on surface release (#20708) * Fix surface release fence recovery floor * fix(agents): advance backup recovery floor past lost mint * fix(hooks): actually terminate a timed-out hook's process tree (#20576) Repairs #20559, whose termination was a no-op: `detached` is a spawn-only option and `exec` ignored it, so the shell never became a group leader. Verified against real processes. Refs #19334 * fix(worktrees): safely remove prunable git-file registrations (#20617) Preserve checkout files and the named branch when removing a positively attested malformed Git-file registration. Reject file/symlink targets in deferred directory deletion. Verified exact head with 75 focused tests including actual Git malformation, preserved marker/file bytes and branch HEAD. Independent review and complete product CI passed. WSL routing is covered by unit tests; direct SSH fails safely without local recovery. Fixes #17316 * fix: keep OMP terminals when folder workspaces become Git repos (#20653) Preserve the original folder locator through Git upgrade and subsequent listing, persistence, and removal decisions after proving it still names the same checkout. Independently reviewed with 60 focused persistence/listing/removal tests and six native Windows real-Git/NTFS cases covering case/slashes, junction retention and retargeting, remote-host isolation and unrelated checkout preservation. Prior source-connected native OMP proof confirms process survival. Full PR CI passed; no rebuilt full-app after-proof claimed. * fix(native-chat): cancel pending prompts precisely (#20601) * fix(native-chat): hide activity while awaiting input * fix(native-chat): keep approval turns cancellable * test(native-chat): satisfy split PR quality gate * fix(native-chat): catalog approval cancellation label * fix(native-chat): include approval cancellation runtime label * fix(codex): settle prompts when cancelled turns complete * fix(codex): settle prompt registry fallbacks * test(native-chat): cover pending interaction fallbacks * test(native-chat): split prompt state coverage * test(native-chat): keep prompt state isolated * fix(native-chat): bound prompt turn backfill * refactor(codex): centralize prompt registry bounds * fix(native-chat): cancel pending prompts precisely * fix(native-chat): consolidate capability imports * fix(native-chat): harden precise prompt cancellation * fix claude cancellation teardown races * retry claude prompt lifecycle admission * bound claude prompt cancellation retry work * fix(codex): bound prompt turn identity on registration * fix(native-chat): route rejected late dispatch settlements * fix(codex): retain exact cancellable prompt turn ids --------- Co-authored-by: Merge Sim <sim@local> * fix(omp): resume independent child sessions from history (#20629) Add Resume to eligible local OMP child history rows. Resolve lazy child targets from their own cwd and host, never an unrelated active workspace. Unresolved folder-only targets stay disabled; copy-command remains available. Verified production map/resume resolver regression before/after; 50 focused tests and independent 40-test review, web types and code quality passed. Actual OMP storage/CLI smoke confirms distinct child/grandchild sessions. No native Windows or live SSH launch claim. Addresses #12885 Scope 1. * fix(ai-vault): expand nested OMP session history (#20663) Expand saved OMP descendants lazily while preserving exact c…

…anner service behind a setting (stablyai#20516) * feat(ai-vault-search): persist agent-session search consent and retention Two booleans and nothing else: `enabled` and `historyDays`, off by default because building the index reads every transcript on the machine. No `paused` -- the PR 3 indexer is immutable, so every change is close-and-construct. The settings IPC normalizes a write like every other field and hands the change to the index; there is no UI for it until PR 8. * feat(ai-vault-search): hold one indexer and engine pair per host The object that owns a host's live index and the three recipes that change it. The indexer is immutable, so a settings change is close-and-construct, disabling is close with no replacement, and clearing is close, remove the database, construct. The new instance's first sweep purges a narrowed window and admits a widened one, so neither needs a code path. The database sits beside the scanner's parse cache, one file per host. A runtime with no node:sqlite can hold no index at all, which the Node 18 floor on orcad and the relay makes a real case rather than a hypothetical one. * feat(ai-vault): let the scanner child own the session search index The transcript reader runs in that child, so the index consumer has to as well: one read serves both the session list and the index. Three request operations (search, status, reconcile) and one fire-and-forget settings message carry everything a parent needs; main never opens the database file. The init frame becomes a factory because it is read at every spawn, so a respawned child sees current consent rather than the first frame's. A child holding a running index is never idle from the parent's side, so idle retirement is suppressed while the index is on -- retiring it would stop the reconcile loop until some later scan happened to respawn one. Both files this lands in were already at the max-lines ceiling, so three collaborators move to where they belong rather than being disabled around: the invalidation deadline into the class that owns invalidations, call cancellation and the start requeue into the call-state module, and orcad's flag parsing into its own file. * feat(ai-vault-search): register a search service on every host that answers Without a registered service a host answers no-service, which means "this host does not have the feature" rather than "the index is off". All three hosts now answer the second thing. The desktop forwards to the scanner child. orcad and the SSH relay daemon have no such child -- orcad ships only the watcher and daemon entries, and the relay's AI Vault sidecar runs the remote scanner, which publishes nothing to the transcript channel -- so on those two the index lives in the process that would drive its reads, gated on a runtime that has node:sqlite at all. The relay registers with consent off and no way to turn it on: nothing carries a setting to a remote host yet. That is the honest state, and it is still worth registering, because it is what tells a client the difference between off and too old. * test(ai-vault-search): price a warm pass over five thousand transcripts The number the reconcile interval will be revisited against, measured rather than argued: a warm sweep stats every file under every root, a warm cycle stats the newest N per agent, and neither reads what the index already holds. It does not tune the interval. * fix(ai-vault-search): answer the casting gate without assertions main's new type-assertion rule reaches every file this branch touches. All nine sites drop the cast rather than carry a SAFETY: rationale: the operation guard narrows with `in`, the sqlite probe narrows the builtin it loads, the child test keeps the discriminated reply instead of widening it, and the settings resolver takes `unknown` -- which is what it really reads, since a persisted profile can hold a value no version of this code wrote. * fix(ai-vault-search): let a refreshed scan root reach the live index The parent re-resolves scan roots before every policy push, precisely so a WSL distro or extra Codex home that appeared since the child spawned enters the window. The child forwarded only the settings to a live instance and used the roots solely in its `??=` initializer, so those roots were dropped for the child's lifetime. The indexer stays immutable: a structurally different root set closes the pair and constructs a new one, the same way a changed databasePath already does. Compare via `sameSessionSearchRoots` rather than a plain JSON compare, because nothing fixes the key order two producers write; lists are sorted too, since the indexer walks every root and a re-enumeration that reorders is not a change. An unchanged set still never restarts a running index. The orcad and relay in-process hosts resolve roots once at install and never re-apply, so they have no such seam. * fix(ai-vault): restart the scanner child the index is holding Three review items. The hold keeps a child alive for the index, but only a queued call ever started one: `pump()` skipped a hold with an empty queue, so an idle indexing child that crashed, or an `ensureChild()` that failed at start, left indexing stopped until an unrelated request happened to arrive. `pump()` now starts the child the hold requires, which is also the restart callback the fault policy already schedules, so the existing delay and circuit bound the retry exactly as they bound a queued call's start. `updateSessionSearch` goes through the same seam instead of its own `ensureChild` call. A search registers no AbortController, so a cancel sent for a search id was added to the `cancelled` set and never consumed. Nothing can reach that today -- no caller passes a signal and the child answers in milliseconds -- so this is only a leak of ids: consume it when the search settles. The orcad argument doc claimed a `--`-prefixed value stays a flag. The parser takes the next token regardless, and orcad-launch-contract.test.ts pins that, so the doc is what was wrong. Behaviour is unchanged. * fix(ai-vault): recover search indexing and refresh scan roots * fix(ai-vault): defer search refresh policy reads * fix(session-search): stabilize paging and host enablement * fix(session-search): refresh host roots within full sweeps * docs(session-search): clarify initial root fallback

* fix(mobile): give the page its height and its long press; C1.7 device proof (OTA phase C, C1.9) (#21589) * fix(mobile): give the Route A document the height its mounted tree measures against (OTA phase C, C1.9) The document this builder emits carries no stylesheet, so `html`, `body` and `#root` have no height, and every box react-native-web lays out below the mount is `flex: 1` against a parent that measures 0. The collapse is silent in every check that existed: the entry stamps `mounted`, the route tree commits, `innerText` holds every row, and the accessibility tree reports each one at the offset it would have had. Nothing is painted below the header, and nothing takes a tap — the list sits inside a scroller the collapse clipped, and a phone reads it to VoiceOver while no row responds. Lane C1.7 found it on both an iPhone 17 Pro simulator and a Pixel 9 Pro emulator, and the same bytes reproduce it in headless Chromium. The fix is the reset Expo's own web template ships for a react-native-web root, emitted inline because the shell's CSP already allows `style-src 'unsafe-inline'` for the sheet react-native-web injects at runtime; a linked asset would paint the collapsed layout until it landed. The render check gains the assertion that would have caught it: the root's box measured against the viewport, and the one control this route paints with no RPC answered — the New Workspace button, positioned against the bottom of the root, which the collapse moved to y = -72 — asked for by `elementFromPoint` at its own centre. Laid out is not reachable, so the check is a hit test and not another read of the DOM. Without the reset it fails `expected +0 to be 844`. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * fix(mobile): let the page have the long press WebKit was taking (OTA phase C, C1.9) The shell's WKWebView is built with the default text interaction, so WebKit installs its selection assistant over the page. A hold on a worktree row raises the selection loupe over the row's own text and the touch is cancelled before the page's responder sees it, which leaves every long-press action in the page dead on iOS while a tap works. Lane C1.7 measured it: the same injected hold opens the row action sheet on the native list and on the page in the Android WebView, and does nothing in the page on iOS. It is not the document's to fix, which the device disproved one rule at a time: `-webkit-touch-callout: none`, `-webkit-user-select: none`, and both together all left the loupe and left the hold undelivered, and headless Chromium confirms the property computes to `none` on the page's text, so the CSS reaches it and WebKit's own gesture wins anyway. The cost is real and named here rather than discovered later: the page has no text selection on iOS, so selectable `Text` — markdown, diff rows, file preview, chat — cannot be selected there until a page-side copy affordance exists. Everything the shell already forbids is unchanged, and Android is untouched. No unit test: the module's Swift checks compile the seven WebKit-free logic files and never import WebKit, so a `WKWebViewConfiguration` cannot be built in them. The device proof stands in. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * fix(mobile): make the root reset the template's bytes, not a copy with an addition The comment said the reset is what Expo's web template ships, and `margin:0` was not in it. `@expo/cli@55.0.36/static/template/index.html` carries height, `overflow` and the root's flex box and nothing else, and react-native-web emits `body{margin:0}` in the sheet it injects at runtime, so the addition only covered the frames before that sheet landed. Nothing pinned it either: removing it left all 60 tests green, which is the other way of saying it was never load-bearing. Dropping it makes the string one thing with one source instead of a copy to keep in step with two. The pins on the rest of the reset are unchanged, and so is the frame that mattered: the root still has a definite height before the first paint, which is what the collapse needed. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * style(mobile): format the render check with the root formatter `config/scripts` is formatted by the root oxfmt, not mobile's, and CI checks neither, so a 102-char line I added sat over the root's `printWidth: 100` with nothing to catch it. Reflowed by `./node_modules/.bin/oxfmt --write` from the repo root; no behaviour change. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * docs(mobile): say what the root reset shares with Expo's template, not that it is its bytes "The bytes Expo's web template ships" is false and checkable: the template's own block is pretty-printed with comments and trailing semicolons at 410 bytes, and this string is 112. What is actually true, and what the next reader needs, is that it carries the same declaration set and the same `id="expo-reset"`, minified. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): pin every rule of the root reset, not two substrings of itself The check read the constant back against itself: `toContain(MOBILE_WEB_APP_ROOT_RESET)` plus two substrings taken off that same constant. A rule dropped from it took the assertion with it, so `body{overflow:hidden}`, `flex:1` and the `expo-reset` id were unpinned — and the render check stays green without the overflow rule, so nothing else held them either. Each rule is now a literal written here, named one at a time so a failure says which one went, and the id is pinned beside them. Verified red-first: removing the overflow rule, the `flex:1`, or the id each fails this test and only this test. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * fix(runtime): detect a same-size terminal artifact swap the granted stat cannot see (#21436) * fix(runtime): detect a same-size terminal artifact swap the granted stat cannot see A local terminal-artifact grant pinned the file as `dev:ino:nlink:size:mtimeMs`. On Linux every one of those can survive an unlink+recreate: ext4 reuses the just-freed inode (measured: 100% of the time), nlink and size are unchanged for a same-size replacement, and the mtime clock is tick-quantized to 1ms, so a swap inside one tick produces a byte-identical identity string. The grant then served the attacker's bytes as if nothing had changed. Local grants now also pin a sha256 of the artifact's content, taken from the same handle as the stat so nothing can swap the file between them, and every local read, preview and write re-checks it before returning or committing content. The stat identity string itself is unchanged: the relay recomputes it verbatim to honour `expectedStatIdentity`, so its format is a wire contract. Remote grants keep the stat-only check and are untouched. This is also the mechanism behind the intermittent `orca-runtime-files-terminal-artifact-io.test.ts` failure on `rejects stale absolute terminal artifact previews before returning changed content`: it replaces an 8-byte artifact with 8 different bytes, so whenever the two writes shared a 1ms tick the product genuinely could not tell them apart. * docs(runtime): record what the terminal artifact grant checks do not close The digest makes the same-size swap detectable; it does not make the sequence atomic. A reader arriving at the access module would reasonably assume otherwise, so write down the measured limits of the stat identity, why the identity string cannot change, and the four windows that stay open — the write path's surviving rename() gap above all. * fix(remote): reassert terminal geometry after reveal (#21568) * fix(remote): reassert terminal geometry after reveal * test(remote): expose layout queues through fixture * test(remote): narrow layout target assertion * fix(omp): submit large prompts in one PTY frame (#21573) * fix(omp): join prompt submit with large paste * test(omp): cover joined submit timing * ci: rerun PR checks after timing test fix * test(omp): acknowledge joined submit activity * fix(mobile): let the shell's page paint a file preview (OTA phase C, C3.0) (#21591) * fix(mobile): let the shell's page paint a file preview A file preview has one shape on the wire: the desktop answers a base64 body and `normalizeMobileFilePreviewResult` composes `data:<mime>;base64,<content>` for React Native Web's `Image`. Under `img-src 'self'` the browser refuses to load it, so every image preview in the page paints nothing — reproduced in the render check, which logged the refusal naming `img-src 'self'` before this. `data:` is granted to images and to nothing else, so what it admits is what the page itself composed out of a reply it already holds; `script-src 'self'` and `connect-src 'self'` are untouched, and `blob:` is not added because nothing in the closure needs one. Both platform pins narrow from "the header contains no `data:`" to "`data:` appears on `img-src` and nowhere else", which is the check that still fails if a later directive grows one. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * docs(mobile): say what the data: image case actually loads through Round 1 is right on both counts. In react-native-web 0.21.2 the hidden <img> the Image component renders carries `alt`, `style`, `draggable`, `ref` and `src` and no load handlers at all — it is there for the browser's image context menu and for `getBackgroundSize()`. The load signal comes from `ImageLoader.load`, which is `new window.Image()` with `onload`/`onerror` on it, so the `new Image()` in this case is the same mechanism the screen's own load runs through rather than a stand-in for it. And the screen maps `onImageError` to "Unable to load preview" (`MobileFilePreviewScreen.tsx:282`); "Binary preview unavailable" is the normalizer's `binary_file` branch, which a CSP refusal never reaches. Comment only. No assertion moves. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * docs(mobile): state the img-src data: bound as the destination, not provenance "admits only what the page itself built" read as a provenance guarantee, and CSP has none to give: `data:` is matched as a scheme, so the directive admits any `data:` image URL and the browser cannot tell one the page composed from one it was handed. Nor is the content the page's own — the mime type and the base64 body both come from the host, and `normalizeImagePreviewResult` only checks the mime type is a non-empty string. The true bound is where the URL goes: it is never fetched as anything but an image, `img-src` is the only directive admitting it, an image fetch executes nothing (an SVG inside an `<img>` runs no script), and `script-src 'self'`, `connect-src 'self'` and `object-src 'none'` are untouched. Both copies reworded identically, since they are kept in step by the render check's own policy comparison. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * Update README downloads badge * fix(claude): stream transcript ancestry proofs Stream transcript ancestry proofs without loading whole histories into memory. * fix: read crash diagnostics without loading whole dumps into memory Read crash diagnostics incrementally to avoid whole-dump memory spikes. * ci: cache cloud workspace packages in unit tests Include the cloud lockfile in the unit-test dependency cache key so repeated runs reuse cloud package downloads. * fix(editor): share code-fence boundaries for Markdown links (#21574) * fix(editor): share fence boundaries for Markdown links * test(editor): assert highlighted lines across Monaco token spans * perf(editor): scan fence lines without substring allocations * fix(editor): match fence suffix whitespace rules * ci: isolate cloud relay tests from unit shards Run cloud relay integration tests once and exclude them from general shards, while caching the cloud lockfile inputs. * fix(omp): acknowledge completion delivery and retire stale retries * fix(omp): acknowledge completion delivery and retire stale retries Co-authored-by: Tim Maximilian Lucas <7103424+timaxlucas@users.noreply.github.com> * test(omp): exercise completion recovery over native HTTP in platform CI * test(omp): verify rendered status clears after completion retry --------- Co-authored-by: Tim Maximilian Lucas <7103424+timaxlucas@users.noreply.github.com> * fix(omp): load task drafts through the status extension * fix(omp): load task prefill through the status extension * test(omp): capture installed runtime task prefill in hidden Orca * fix(omp): resolve transcripts from active XDG and profile roots (#20633) * fix(omp): resolve XDG session root fallback * fix(omp): share profile-aware transcript root resolution * test: verify actual OMP XDG transcript discovery and reading * test(omp): satisfy reader smoke loop lint * test(omp): resolve vault fixture paths without redundant cache * fix(omp): refuse normalized Windows drive-relative roots * fix: check host ownership before recovering OMP sessions (#20628) * fix: gate startup agent recovery on host inventory * fix: defer recovery while a live agent lacks conversation ownership * fix(mobile): two known main bugs the RPC migration preserved (#20563) * fix(mobile): two known main bugs the RPC migration preserved A malformed host `error` and a null settings result both reach a property read that throws. Both are deliberate behaviour changes; the goldens move in the follow-up commit. `hostReplyErrorTextOrFallback` passed a truthy non-string through under a `string` annotation. Its one caller is the in-band `git.commit` failure, and every consumer of that text is display or prompt copy: `use-mobile-create-pr-runner` and `PrSidebarCreateEmptyState` record it as a commit failure, `use-mobile-commit-failure-recovery` hands it to `summarizeCommitFailure`, which starts with `raw.slice(...).replace(...)`. So no consumer needs the value, and the decision is the fallback rather than `String(value)` — the relay handler declares `commit(): Promise<{ success: boolean; error?: string }>`, so a non-string is a malformed reply, and `generatedCommitMessageReader` in the same domain already reads a non-string host error as absent. The parameter stays `unknown`, which it honestly is, and the `SAFETY` cast is gone. `useNewWorkspaceRuntimeContext` read settings through `settingsRead`, whose reader preserves main's `boxed!.settings` throw, so a `null` or absent result threw a TypeError out of the effect — losing the trusted-hooks publish and the available-provider computation that follow it, not just the settings. It now uses `optionalSettingsRead`, the operation that already reads a null or absent result as absent settings, so the reply degrades exactly the way a reply with no `settings` member does. Reply-side only: same method, same params, same barrier, no wire change. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): re-record the goldens the two bug fixes move Baseline bumped to 3f71999237. Two goldens move an observation; the other 151 move only `baseline` and `recorderSha256`, which `pilot-scenarios.json` is still digested into. Observation moves, one claim each: - `matrix-hostedreview.create-intent-git.commit-1`, partition `inner-false-object-error`: `settlements.run.value.error` and `state.outcome.error` go from `{"message":"inner refused"}` to `"Commit failed"`. A non-string in-band `git.commit` error is a malformed reply and now reads as the screen's copy, converging with `result-absent`, `result-null` and `outer-refused-no-message`, which already reported the fallback. The other ten partitions at this site are unchanged. - `matrix-settings.workspace-context-settings.get-1`, partitions `result-null` and `result-absent`: the `unhandled-rejection` TypeError effect (`reading 'settings'`) is gone and `state.providers` goes from `[]` to `["github"]`. The effect no longer aborts the rest of the hook, so the provider computation runs; `state.settings` stays null because nothing was published, which is how a reply with no `settings` member already degraded. The other nine partitions are unchanged. Header-only moves: - 9 goldens of the `settings.workspace-context` family rename `namedDeltas` from `new-workspace-runtime-context-null-settings-typeerror` — the name now lies, the TypeError is fixed — to `new-workspace-runtime-context-null-settings-degrades-to-absent`. - All 153 move `baseline` and `recorderSha256`. The digest covers `pilot-scenarios.json`, so the baseline bump and the rename re-digest every file. No sender recording moved: both fixes are reply-side, and no golden's `sender` or `payloads` field differs. The README paragraph that claimed the settings TypeError was preserved is updated, and now records that the `ui.get` leg of the same hook still is. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * fix(mobile): degrade a null ui.get result the way the settings leg now does One host answers both legs of useNewWorkspaceRuntimeContext, so fixing only settings.get left the likelier failure in place: a null or absent ui.get result still threw `reading 'ui'` out of the effect, skipping the provider commit. Review follow-ups on the same files: reply() returns the literal uncast and the stub client is FakeSession, dropping two assertions and their SAFETY disables; the degradation cases now assert absolute state instead of comparing mounts. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): re-record the goldens the ui.get leg fix moves Observational move, 1 golden: - matrix-settings.workspace-context-ui.get-1: the `result-absent` and `result-null` partitions drop their `reading 'ui'` unhandled-rejection effect and their state commits `providers: ["github"]` instead of `[]`, because the effect no longer throws before the provider commit. Header-only moves, 153 goldens: `baseline` to the fix commit and `recorderSha256`, which covers `pilot-scenarios.json` and so re-digests on the delta rename. The delta is renamed `new-workspace-runtime-context-null-settings-degrades-to-absent` -> `new-workspace-runtime-context-null-results-degrade-to-absent` (9 goldens): it now covers both reads, not just settings. README updated to match. No sender recording moved: resolving the value pool across all 153 goldens shows `sender` and `payloads` byte-identical everywhere. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * refactor(mobile): name the ui.get result shape so the changed cast carries a rationale The inline union wrapped over four lines and tripped the changed-code casting gate as a new assertion; a named alias keeps the cast on one line under a SAFETY note. No behaviour change. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): repin the golden baseline to the cast-rationale commit Header-only: `baseline` on all 153 goldens. The re-record is inert — no golden moves observationally and no field other than `baseline` changes. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): pin the ui.get trust blank, and correct two stale acceptance comments The goldens cannot catch a regression to `if (uiResult?.result)`: the scenario's success reply is `{"ui":{}}`, so every partition of matrix-settings.workspace-context-ui.get-1 records the same `trust:{}` state. The new case answers once with real trust and again with a null result on a fresh client, which is the only shape where skipping the blank is observable — trustedOrcaHooks gates the setup-hook approval prompt in use-new-workspace-create-submit.ts, so a stale value would skip it. settingsRead's comment still claimed workspace context, which this branch moved to optionalSettingsRead; both comments now name their real callers. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): repin the golden baseline to the trust-blank commit The record fence rejected the previous pin ("Product sources or lockfile differ from the pinned main baseline"), so the branch was no longer re-recordable. Header-only: `baseline` and `recorderSha256` on all 153 goldens — the digest covers pilot-scenarios.json, whose only edit is that baseline. The re-record is inert: 0 goldens move observationally and no other field changes. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * docs(mobile): name the right operation per refuse-after-data probe Three of the five probes read through optionalSettingsRead, not settingsRead: repo metadata and resume metadata already did, and workspace context does as of this branch. The sentence now splits them and states why the split does not move what the probes record. Markdown is excluded from recorderSha256, so no re-record. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): pin the recorder's unhandled-rejection capture This branch removed the last two goldens that recorded an unhandled-rejection effect, so nothing exercised unhandled-recording.ts any more: gutting the emit to `void captureError(error)` leaves all 153 goldens comparing clean. The unit test drives a detached rejection through the window and asserts both the effect and the listener restore. README says so where it describes the capture. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): re-digest the goldens for the new recorder test Header-only: `recorderSha256` on all 153 goldens, which covers every non-markdown file under rpc-recording/ and so moves for the added test file. The re-record is inert: 0 goldens move observationally and no other field changes. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): pin each RPC golden to its own scenario input, not the whole manifest (#20562) * refactor(mobile): pin each golden to its own scenario input, not the whole manifest `recorderSha256` covered the recorder directory plus `pilot-scenarios.json`, so every golden's header was a function of every other family's scenarios. Adding a family for one domain re-digested all 153 goldens and put a conflict on that line in every domain branch in flight, which serialized the step-4 fan-out. Split the two things it conflated. `recorderSha256` now covers the recorder directory only, with unchanged semantics: a recorder edit still forces a full, deliberate re-record. A new `scenarioSha256` pins the scenario input that golden was recorded from — every scenario `runRecording` consumed for it, in order — canonicalised through `captureValue` so an explicit-undefined param stays distinct from an absent one. `goldenRecording` takes that list instead of just its first member. The variants are hashed rather than the base they expand from because they are what was recorded: a matrix site, its replayed normal result and its partition replies are all visible in them without the derivation having to be restated. `derived-goldens.ts` is that derivation, extracted from `family-recordings.test.ts` so the digest and the recording agree by construction — a property test that restated how a matrix or schedule expands could agree with itself and with nothing else. It reproduces exactly the 153 golden ids on disk, and the census the suite already ran (every family matrixed, no stale normal-result inventory entry) now reads off its output. `golden-header-digest.test.ts` pins the four properties: - a new family in the manifest moves zero existing goldens' headers, and derives two of its own - editing one field of `b1` moves exactly `b1` and its family's four matrix goldens — not the two other `legacy-inventory` scenarios, and not the goldens that expand from `inventory-lifecycle` - editing a recorder file still moves every golden's `recorderSha256`, and no `scenarioSha256` - `recorderSha256` is unchanged by the manifest's contents, and no longer reads the file at all `GOLDEN_FORMAT_VERSION` goes to 4: a version-3 header has no `scenarioSha256`, and `compareGolden` walks the expected header's keys, so a reader that accepted one would compare that golden's own scenarios as though they were unpinned. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): re-record the 153 RPC goldens for the split digest Recorder edit, so every golden needs rewriting. Recorded from the pinned baseline `16d1ab81d3` with this branch's recorder overlaid, per the README's procedure: main has moved past the baseline, so recording in place would have failed the product-source fence. Three header fields moved and nothing else did: - `recorderSha256` 6a12160a87… -> 2fda557f58…, one value across all 153 files - `scenarioSha256` added, 153 distinct values - `goldenFormatVersion` 3 -> 4 No observation, checkpoint, value-pool entry, `baseline`, `lockfileSha256` or `platform` changed: git diff -U0 -- mobile/rpc-foundation | grep -E '^[+-]' | grep -vE '^(\+\+\+|---)' \ | grep -vcE 'recorderSha256|scenarioSha256|goldenFormatVersion' 0 Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * refactor(mobile): certify the pilot goldens from the derivation that digests them `pilot-recordings.test.ts` restated `[scenario]` instead of consuming `pilotGoldens`, so the claim that a golden's `scenarioSha256` is a function of the same derivation that records the file held only for the 75 family goldens: dropping a scenario from `pilotGoldens` left the whole suite green and put that golden outside the header oracle. The pilot suite now iterates `pilotGoldens`, and a census fails if the derivation and the goldens directory disagree in either direction — which also closes the pre-existing orphan-golden gap. Also from review: pin the cross-sibling replay that hashing the generated variants buys (a matrix golden's `normal` partition replays a sibling's recorded reply, so editing that sibling must move it); state the real reason for the format bump, which is the diagnosis a version check gives rather than a rejection the byte compare already made; drop the fourth property test, which re-proved what tests 1 and 2 and `recording-runner`'s digest test already fail on; and drop a guard in `scenarioSha256` that its only caller reaches after an identical one. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): re-record the 153 RPC goldens for the review edits Recorder files changed, so `recorderSha256` moved. Recorded from the pinned baseline with this branch's recorder laid over it, per the README's migration-branch procedure. That one header field is the only line that moved in all 153 files: `scenarioSha256` and `goldenFormatVersion` are unchanged, and no observation moved. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * docs(mobile): correct the recording suite's test count Round-2 review: the README said 200 tests; the suite is 209 after the five added here. Markdown is outside recorderSha256, so no golden moves. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): re-record the 153 goldens on the merged baseline Four header fields moved and nothing else. Proven against origin/main: every changed line in all 153 files is one of these, and the file set is unchanged. - `recorderSha256` 70aa6f59e0 -> 58a461dbc9: this branch's recorder, and it now digests only the recorder directory, not the scenario manifest. - `scenarioSha256` added, 153 distinct values over 153 goldens. - `goldenFormatVersion` 3 -> 4 for that added field. - `baseline` 5ec0b2698f -> e53f1557e1, the merge's repoint onto the real main commit. #20563's value was a branch commit the squash left unreachable, so the record fence's `git diff <baseline>` could not resolve it. No checkpoint, value pool, effect or settlement byte moved, so main's recorded behaviour is carried over intact. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * docs(mobile): account for main's added recorder test in the suite count The merge brought in `unhandled-recording.test.ts`, one test, so the recording suite is 210 rather than the 209 this branch documented. Markdown is excluded from `recorderSha256`, so no golden moves. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * fix(native-chat): stop a bounded tail read from moving the chat cursor past unapplied rows (#20581) * fix(native-chat): stop a bounded tail read from moving the chat cursor past unapplied rows A structured chat pane could latch "Working for N" forever after the agent had finished, showing the send arrow rather than Stop, while the sidebar and `worktree ps` correctly read idle. The client replica has one position (`state.cursor`) and one body. Two operations keep those consistent: replace (both from one host snapshot) and append (rows contiguous with the cursor). The `tail-page` branch was a third thing: it took the cursor from the journal head, the items from a bounded page (200 items, byte-capped), then merged retained client submissions over the page's. Under continuous journal writes the client is always slightly behind, so the branch ran on every window focus and on every pane re-activation. When more than a page of rows had landed since a send, that send's user item fell off the page, its submission was not carried, the retained `pending` survived, and the cursor jumped past the dispatch-acceptance row. Nothing re-sends it: a batch carries only touched items and that submission is never touched again. Delete the third operation rather than guard it. A live subscription is now the only thing that moves the cursor, and `subscribe({ cursor })` already replays exactly the missed rows. - remove the window `focus` listener and the owner/transport `refresh` contract - skip warm hydration: a retained owner subscribes at its applied cursor - cold hydration keeps its history read, applied as the existing `snapshot` (replace) event rather than `tail-page` - delete the `tail-page` action and its reducer branch - delete `resumeCursor` and `shouldAdvanceStructuredResumeCursor`; two cursors with two advancement rules were how position and body drifted apart `older-page`/`loadOlder`, the unattached-refusal grace, generation guards and the coalescer are unchanged. No host, wire or schema change. Also fixes a second cost of the same branch: focus during a busy turn discarded paged-in older items, shrinking the transcript to one bounded page mid-turn. * fix(native-chat): preserve unavailable mixed-version session fences * refactor(mobile): send the task workspace-creation domain through typed RpcOperations (#20568) * test(mobile): record main's task workspace-creation RPC behaviour before migrating it 28 scenarios over nine task senders, recorded from main so the step-4 migration of the workspace-creation half of src/tasks/ has a frozen answer to compare against. Four senders mount as plain exported functions; three are model-chained hooks mounted the way the settings adapters mount theirs. The 153 existing goldens change header-only (`baseline`, `recorderSha256`): any new scenario re-digests the recorder, and the pinned baseline had drifted from main because the source-control migration landed. Content is byte-identical on all 153 — verified field-by-field against HEAD. `operation-module-loader.ts` now shares src/transport/rpc-delivery-ambiguity.ts with mounted modules instead of evaluating a second copy. The mark is a WeakSet keyed on the rejection object, so the copy the loader built had an empty registry and every delivery-unknown rejection read as a definite failure inside the operation under test — worktree.create's whole replay path was unreachable. With one registry, `tw-create-retry-ambiguous-after-drop` records the create still pending at the reconnect wait and abandoning at exactly 20000 ms, while the unstamped-create scenario records the same rejection surfacing at 0 ms. No existing golden moves: no other mounted module consumes the mark. `task-preferences-optimistic` is re-anchored above the send rather than across it, so migrating this file does not have to move the anchor. It still kills, and for the same reason: the preset the screen shows no longer follows the tap. Scenarios deliberately pin the empty-message refusals (`*-refused-empty-message`, `*-empty-message`), because a refusal with no message falls back to the screen's copy while a transport error with no message does not, and the two paths are easy to collapse when a call site moves behind an acceptance policy. Goldens: 153 -> 201, 2.9M -> 3.7M. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): format the recording manifest and re-digest the goldens `oxfmt --check` from mobile/ collapses a one-element `sites` array in each new scenario. The JSON value is unchanged — verified by comparing both files parsed and key-sorted — but the manifest is inside `recorderSha256`, so all 201 goldens carry a new digest. Every other field, header and observation alike, is byte-identical. Re-recorded in a separate worktree at the previous commit so the goldens stay attributable to main's product source rather than to the migration that follows. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): separate the goldens from the migration, and re-digest The previous commit accidentally carried the product migration alongside the manifest format, which both broke the commit that is supposed to prove parity and left the suite red: the digest was recorded without a comment move that a lint fix had made inside the adapter, so all 201 goldens failed their `recorderSha256` header. This backs the product half straight out again — the next commit re-applies it byte-for-byte — and re-records from the pinned baseline in a separate worktree carrying this branch's recorder, per the procedure in the recording README. Every field except `recorderSha256` is byte-identical to the previous commit's goldens on all 201 files, so no observation moved in either direction. The suite is green here with main's product source, which is what makes the next commit's "no golden changed" claim mean something. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * refactor(mobile): send the task workspace-creation domain through typed RpcOperations 12 of src/tasks/'s 37 raw-port files now send through a declared operation instead of the raw request port: 36 references to 0, leaving 25 files and 73 references for the provider item/detail/mutation half. No golden moved — `git show --stat` on this commit touches nothing under mobile/rpc-foundation/, which is the parity claim. Twenty-two operations over twenty methods, in four modules named for what they send: workspace create (create, PR/MR base resolution, create-time capabilities), workspace source (SSH connect/state, agent detection, repo hooks, sparse presets, ref search), task runtime (status, ui.get/ui.set, preflight, Linear status, settings.update) and the Smart picker's provider reads. Two methods carry two policies each, and both pairs are named. `status.get`: the Tasks screen cannot hydrate without it and surfaces the host's message, while create-time capability probing degrades to "no capabilities" and creates anyway — so one throws on refusal and one skips. `ui.set`: two sites await it, one is fire-and-forget and never interprets the reply at all. Both pairs share one reader, so no method has two readers. No new acceptance policy. worktree.create keeps its delivery-unknown contract. `request` returns the transport promise itself, so the retry loop catches the object the transport marked; two new tests assert `toBe(marked)` in one direction and that an unmarked rejection stays unmarked in the other, because a mark added on the way out would replay a create the host never received. `tw-create-retry-ambiguous-after-drop` records the create still pending at the reconnect wait and abandoning at exactly 20000 ms. Three sites still read the raw refusal envelope before interpreting, because the code or the message decides the route and no acceptance policy carries either through: the create retry needs the message for `isRetryableWorktreeCreateConflict`, and the paste lookup needs `method_not_found` to retire the slug probe host-wide. Both are documented at the site. The hydration barrier keeps raw requests inside its `Promise.all`. main's group rejects as soon as one leg rejects; `startRpcOperation` + `interpretAtRpcBarrier` would wait for the slowest peer and let a later policy surface a different error. Interpretation stays after the `stale` guard, where it was. `WorkspaceCreateParams` is now `RpcSendParams<'worktree.create'>` rather than `Record<string, unknown>`, which types the builder and the operation together; every field the three builders already sent typechecks against the host schema unchanged. `RpcSendArguments` now also makes params optional for a method whose params type has no required field, because `preflight.check` is such a method and main sent it none — requiring `{}` would have put a new object on the wire. The Mobile Tasks source-parity hashes move for the same reason bound settings requests moved them: the method string and the envelope read leave the screen. The signature diff is evidence rather than a re-pin — `semantics` is a pure deletion of 22 `rpc:` call signatures and 22 method literals with nothing added, statement/declaration/render/style counts are unchanged, and render tokens, styles and declarations are byte-identical. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): split the task workspace adapters at the sender/hook seam The single adapter file reached 344 lines against mobile's 300-line limit. CI lints every file, so this is red there even though the changed-code gate does not report it. Split along the seam the recording README already draws: exported async senders that take a client and need no React host, and the drawer's three model-chained hooks. No adapter body changed. Both files are inside `recorderSha256`, so all 201 goldens carry a new digest. Every other field is byte-identical, verified file by file. Re-recorded from the pinned baseline in a separate worktree carrying this branch's recorder, so the goldens stay attributable to main's product source. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * refactor(mobile): give the one-key unchecked reader a name Four readers were the same three lines: read one property off the reply, wrap it unchecked. `rpcUncheckedMemberReader` is the one-key sibling of the existing `rpcUncheckedPayloadReader`, so the annotation and the closure go away at each site. The pilot's `commitCompareEntriesReader` is converted too, so the helper has no longhand twin left to copy from. No behaviour change: the helper composes the same `rpcReadUnchecked` over `rpcPayloadMember`, including the property-read exception on a null result. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): record the local arm of workspace agent detection `preflight.detectAgents` was the one migrated operation with no recorded coverage: the ssh adapter hardcoded `connectionId: 'ssh-1'`, so the detection effect's ternary only ever took the remote arm and the local call site could be repointed at another method without a golden noticing. The adapter now takes the connectionId as a parameter and registers twice; `tasks.workspace-ssh-local` mounts the same hook with no connection, which is the only difference the effect branches on. Recorded at the pinned baseline with this branch's recorder laid over it, so the new golden is main's behaviour and the migrated code has to reproduce it — it does. Goldens: two added (`tw-workspace-ssh-local-agents` and its reply matrix). The other 201 changed on `recorderSha256` only, because the adapter edit moves the recorder digest every golden pins. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): drive workspace create and the Linear list to a recorded wire Two operations passed a policy swap unnoticed, both because no golden reached their acceptance branch. `worktree.create`: the create hook's fixture resolved setup to a prompt, so all three settings.task-workspace scenarios stopped before the request and the only consumer that hands a refusal to interpret was never recorded. The adapter now takes the setup resolution as a parameter and registers a second family that resolves it, so createWorkspace runs to the wire. Two scenarios: a Linear item that creates directly, and a GitHub pull request that resolves its base first, which also puts this hook's built params — start point, generated display name, agent launch fields — in a golden for the first time. The existing prompt family is untouched, so its recordings still pin that branch. `linear.listIssues`: it appeared only in a non-base scenario, and the matrix reads the family base, so the family had no partition for it. The base now lists assigned issues after searching. Goldens: five added. Five moved beyond the digest, all derived from the smart-search base that gained the list leg. The other 198 changed on `recorderSha256` only. Recorded at the pinned baseline with this branch's recorder laid over it, so every new golden is main's behaviour. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): drop the unreachable unmount branches from the task adapters Nothing dispatches `unmount` to these three adapters: the only producer is `lifecycleSchedules`, driven from a hardcoded five-id list that names no task-workspace family, and it pushes a `remount` right after, which these adapters would throw on. The branch read as lifecycle coverage that was never wired up. `dispose: hook.unmount` already tears the mount down. Goldens re-recorded at the pinned baseline because the recorder digest moved; `recorderSha256` is the only line that changed in all 208. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): re-record the goldens at main's post-squash baseline Recorded from a detached checkout of e53f1557e1 (main's unmigrated product code) with this branch's recorder laid over it, so the parity claim stays non-circular. - `baseline` repinned to e53f1557e1 on all 208 goldens; main pinned 5ec0b2698f, a pre-squash branch commit not reachable from main. - `recorderSha256` moved on all 208 because this branch's adapters are in the whole-manifest digest. - 55 task-workspace goldens re-recorded at the new baseline. - No other line in any of main's 153 goldens changed. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * test(mobile): re-record the goldens under #20562's per-scenario digest Baseline repinned to 50e752fc66 and all 208 goldens recorded from that commit's unmigrated product tree with this branch's recorder laid over it. recorderSha256 moves on every golden because the task-workspace adapters live in the recorder directory. scenarioSha256 does not move on any of main's 153: the manifest only adds 31 scenarios and edits none, which is the property #20562 was built to give. Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb * feat(ai-vault-search): construct the session search indexer in the scanner service behind a setting (#20516) * feat(ai-vault-search): persist agent-session search consent and retention Two booleans and nothing else: `enabled` and `historyDays`, off by default because building the index reads every transcript on the machine. No `paused` -- the PR 3 indexer is immutable, so every change is close-and-construct. The settings IPC normalizes a write like every other field and hands the change to the index; there is no UI for it until PR 8. * feat(ai-vault-search): hold one indexer and engine pair per host The object that owns a host's live index and the three recipes that change it. The indexer is immutable, so a settings change is close-and-construct, disabling is close with no replacement, and clearing is close, remove the database, construct. The new instance's first sweep purges a narrowed window and admits a widened one, so neither needs a code path. The database sits beside the scanner's parse cache, one file per host. A runtime with no node:sqlite can hold no index at all, which the Node 18 floor on orcad and the relay makes a real case rather than a hypothetical one. * feat(ai-vault): let the scanner child own the session search index The transcript reader runs in that child, so the index consumer has to as well: one read serves both the session list and the index. Three request operations (search, status, reconcile) and one fire-and-forget settings message carry everything a parent needs; main never opens the database file. The init frame becomes a factory because it is read at every spawn, so a respawned child sees current consent rather than the first frame's. A child holding a running index is never idle from the parent's side, so idle retirement is suppressed while the index is on -- retiring it would stop the reconcile loop until some later scan happened to respawn one. Both files this lands in were already at the max-lines ceiling, so three collaborators move to where they belong rather than being disabled around: the invalidation deadline into the class that owns invalidations, call cancellation and the start requeue into the call-state module, and orcad's flag parsing into its own file. * feat(ai-vault-search): register a search service on every host that answers Without a registered service a host answers no-service, which means "this host does not have the feature" rather than "the index is off". All three hosts now answer the second thing. The desktop forwards to the scanner child. orcad and the SSH relay daemon have no such child -- orcad ships only the watcher and daemon entries, and the relay's AI Vault sidecar runs the remote scanner, which publishes nothing to the transcript channel -- so on those two the index lives in the process that would drive its reads, gated on a runtime that has node:sqlite at all. The relay registers with consent off and no way to turn it on: nothing carries a setting to a remote host yet. That is the honest state, and it is still worth registering, because it is what tells a client the difference between off and too old. * test(ai-vault-search): price a warm pass over five thousand transcripts The number the reconcile interval will be revisited against, measured rather than argued: a warm sweep stats every file under every root, a warm cycle stats the newest N per agent, and neither reads what the index already holds. It does not tune the interval. * fix(ai-vault-search): answer the casting gate without assertions main's new type-assertion rule reaches every file this branch touches. All nine sites drop the cast rather than carry a SAFETY: rationale: the operation guard narrows with `in`, the sqlite probe narrows the builtin it loads, the child test keeps the discriminated reply instead of widening it, and the settings resolver takes `unknown` -- which is what it really reads, since a persisted profile can hold a value no version of this code wrote. * fix(ai-vault-search): let a refreshed scan root reach the live index The parent re-resolves scan roots before every policy push, precisely so a WSL distro or extra Codex home that appeared since the child spawned enters the window. The child forwarded only the settings to a live instance and used the roots solely in its `??=` initializer, so those roots were dropped for the child's lifetime. The indexer stays immutable: a structurally different root set closes the pair and constructs a new one, the same way a changed databasePath already does. Compare via `sameSessionSearchRoots` rather than a plain JSON compare, because nothing fixes the key order two producers write; lists are sorted too, since the indexer walks every root and a re-enumeration that reorders is not a change. An unchanged set still never restarts a running index. The orcad and relay in-process hosts resolve roots once at install and never re-apply, so they have no such seam. * fix(ai-vault): restart the scanner child the index is holding Three review items. The hold keeps a child alive for the index, but only a queued call ever started one: `pump()` skipped a hold with an empty queue, so an idle indexing child that crashed, or an `ensureChild()` that failed at start, left indexing stopped until an unrelated request happened to arrive. `pump()` now starts the child the hold requires, which is also the restart callback the fault policy already schedules, so the existing delay and circuit bound the retry exactly as they bound a queued call's start. `updateSessionSearch` goes through the same seam instead of its own `ensureChild` call. A search registers no AbortController, so a cancel sent for a search id was added to the `cancelled` set and never consumed. Nothing can reach that today -- no caller passes a signal and the child answers in milliseconds -- so this is only a leak of ids: consume it when the search settles. The orcad argument doc claimed a `--`-prefixed value stays a flag. The parser takes the next token regardless, and orcad-launch-contract.test.ts pins that, so the doc is what was wrong. Behaviour is unchanged. * fix(ai-vault): recover search indexing and refresh scan roots * fix(ai-vault): defer search refresh policy reads * fix(session-search): stabilize paging and host enablement * fix(session-search): refresh host roots within full sweeps * docs(session-search): clarify initial root fallback * fix(native-chat): hide activity while awaiting input (#20496) * fix(native-chat): hide activity while awaiting input * fix(native-chat): keep approval turns cancellable * test(native-chat): satisfy split PR quality gate * fix(native-chat): catalog approval cancellation label * fix(native-chat): include approval cancellation runtime label * fix(codex): settle prompts when cancelled turns complete * fix(codex): settle prompt registry fallbacks * test(native-chat): cover pending interaction fallbacks * test(native-chat): split prompt state coverage * test(native-chat): keep prompt state isolated * fix(native-chat): bound prompt turn backfill * refactor(codex): centralize prompt registry bounds --------- Co-authored-by: Merge Sim <sim@local> * Update README downloads badge * Bump mobile app.json to 0.0.50 (#20661) * fix(native-chat): bound a dispatch reason before it reaches the journal row (#20654) `AgentJournalSubmission.reason` was the only unbounded field written by Orca's own code. `dispatchSafely` sets it from the adapter's raw `error.message` and `journalDispatchRowBuilder` stored it verbatim, so a provider error carrying a multi-megabyte body -- a stringified HTTP error payload, say -- reached the row at whatever length the provider sent, and stayed on disk at that size for the life of the journal. It now goes through `boundInlineText` with the journal's existing inline limit, the same idiom already applied to arbitrary text on the Claude and Codex translation paths. The bound must stay head-preserving. `dispatchRejectionWasTransportWriteFailure` prefix-matches the value, and `dispatchRejectionReasonIsInternal` builds on it, so a bound that kept the tail instead would stop classifying a clipped transport failure and render raw provider text to the user as an ordinary rejection notice. A test pins that, and clipping stays marked rather than silent so a truncated reason is never presented as the provider's complete explanation. Rows written before this keep their full text, so readers can still meet an unbounded reason. * fix(native-chat): keep a resumed transcript pinned to its end (#20651) * fix(native-chat): keep a resumed transcript pinned to its end Follow state was recomputed from distance on every scroll event, and a pin writes scrollTop itself, so the browser reports that write back as a scroll event a frame later. Once a resumed session's later history pages and settling row heights had moved the end away from it, that echoed event read as the reader leaving and the pin was dropped for good, stranding them mid-transcript. Measured in Chromium: a pin followed by same-task growth delivers a scroll event reading 2000px from the bottom, indistinguishable from a reader scrolling up. Pins now go through the virtualizer instead of writing scrollTop directly, so both parties resolve the end through the same maximum rather than holding rival definitions of it. Whether the reader left is now a question of provenance rather than distance: an offset this transcript wrote is never a departure. The end test reads live geometry, because the virtualizer's own isAtEnd subtracts a cached offset from a live maximum and this handler runs before that cache is refreshed. overflow-anchor:none stops the engine moving scrollTop under a settling row, which would otherwise look like the reader. This does not make ownership singular. The virtualizer still writes autonomously from several paths and those writes stay unattributed; what this removes is the rival definition of the end, not the second writer. * fix(native-chat): cancel stale end reconciliation * fix(native-chat): attribute scroll ownership centrally * Surface stage, unstage and discard failures with retry capability (#20423) * fix(source-control): surface stage, unstage and discard failures * fix(source-control): use single slot for entry failure toasts - Consolidate entry failures to one stable slot instead of per-worktree - Handle stale retries inline at click time rather than via a cleanup hook - Remove retry button from discard failures to prevent destructive accidents * test: improve type safety and mock patterns in source-control tests - Add proper type definitions for toast options and test data instead of using `as never` - Replace `mock.calls.at(-1)` with safer `mock.lastCall` pattern - Create `entry()` helper to construct typed test entries - Add explicit type annotations to mocked functions for better IDE support * test: extract shared toast options type for source control tests Consolidate duplicate `ToastOptions` type definitions across three test files into a single `SourceControlToastTestOptions` type, reducing duplication and improving consistency. * fix(source-control): separate refresh failures from mutation failures Post-mutation refresh failures are logged separately, not surfaced as toasts (mutation already succeeded). Use preventDefault() on retry to prevent sonner's auto-dismiss from swallowing re-raised failures. Consolidate stage/unstage into a shared handler to reduce duplication. * fix(source-control): only dismiss entry failures from the owning worktre Track which worktree owns the shared entry-failure toast slot. When a mutation completes, only dismiss the slot if the completing worktree is the one that raised the failure — a slow retry in one worktree should not erase a failure another worktree has since raised into the slot. * Remove entry mutation status refresh helper Inlined into the caller during consolidation of failure handling and tracking in the source-control entry mutations flow. * Simplify entry mutation refresh without wrapper Call refreshActiveGitStatusAfterMutation directly instead of through the refreshEntryMutationStatus helper. This ensures refresh failures propagate directly from the callback without being caught as mutation failures. Remove tests that validated the wrapper's error handling. * Add copy button to code blocks (#20357) * feat(native-chat): add copy button to code blocks Enable users to copy code snippets directly from chat messages via a dedicated copy button on fenced code blocks. Supports language detection and integrates with markdown rendering via a `renderCodeBlock` prop. * i18n: add English copy code button label * refactor: use React.isValidElement type parameters for type narrowing - Specify props types as type parameters to React.isValidElement instead of casting after the fact - Allows TypeScript to narrow element.props type automatically - Eliminates manual type assertions in extractCodeText and extractCodeFenceLanguage * fix(source-control): prevent text wrapping in section headers and action buttons (#20046) * fix(source-control): prevent text wrapping in section headers and action Use flex layout constraints (flex-1, shrink-0) and text truncation instead of wrapping to keep section labels and action buttons on a single line in the right sidebar. * test(source-control): add section action button alignment tests Ensure View all button stays on single line with icon actions in crowded section headers. Pin layout constraints (shrink-0, flex-wrap, whitespace-nowrap) to prevent regression. * Rely on Button base styles for action label wrapping Remove redundant shrink-0 and whitespace-nowrap utilities from section action buttons. These should be supplied by the Button component's base variant, not duplicated at each usage site. * fix(store): stop two no-op writes from re-running every selector in the app (#20641) * fix(store): stop two no-op writes from re-running every selector in the app zustand bails out of a `set` only when `Object.is(next, state)`. Two updaters that mean "nothing changed" hand it a fresh reference instead: - `setWorkspacePortScanRefreshing` wrote unconditionally — the one action in its file that did; its four siblings all early-return `state`. - `applyGitHubPRRefreshEvent` ended its no-op branch with `: {}`, and `Object.assign({}, state, {})` reproduces every field unchanged while still notifying. ~20 sibling sites in the same store already use `return state`. Both rebuild the root and wake every subscribed selector (~2.2k per the listener census). Renders are unaffected — the selection is unchanged — so the cost is wasted selector evaluation, not commit pressure. The resulting state looks identical either way, which is why it goes unnoticed; both tests therefore count subscriber notifications rather than asserting state. * test(store): use checked initial state in notification regression --------- Co-authored-by: m4air <m4air@Mac.localdomain> Co-authored-by: Neil <neil@stably.ai> * fix(ai-vault): bound streamed remote JSONL records (#20700) * fix(ci): stop hourly versions dropping below a tagged or already-shipped build (#20699) * fix(ci): stop hourly versions dropping below a tagged or already-shipped build Hourly/daily/adhoc based their X.Y.Z on GitHub releases, not git tags. When v1.4.202 was tagged and then its GitHub release vanished, the next hourlies shipped as 1.4.202-hourly — below both stable 1.4.202 and the 1.4.203-hourly builds already installed, so electron-updater stopped offering updates. Read main's v* tags and already-published channel tags instead. * docs(ci): record that 1.4.202's release was unpublished for a bug The leftover tag is what hourly must still honor; this was not a failed cut. * fix(store): preserve state identity for no-op updater branches (#20703) * fix(codex): settle a structured send on admission, and stop minting a colliding identity (#20138) * fix(codex): settle a structured send on admission, and stop minting a colliding identity Two sends could be written into the journal under one durable identity. Codex coalesces a mid-turn `turn/start` into the running turn rather than refusing it -- measured against real `codex app-server` builds 0.147.0, 0.150.1 and 0.153.4, none of which refuse and none of which fire a second `turn/started`. The dispatch path read the turn id from the turn/start response and stamped every accepted send `ordinal: 0`. Since a coalesced send gets the running turn's id back, two submissions persisted the same `providerItemId`. That string is durable, and it is the key a restore uses to match a submission against provider history, so the second message's real history row matched nothing and rendered as an extra bubble on replay. On 0.147.0 it is worse than a collision: the coalesced response returns a turn id that never starts and never completes, so the persisted key named a turn absent from history and NEITHER message could match. Identity is now minted from the echoed user message at `identityFor` -- the single point that mints the journal row's own identity -- so the settled key is by construction the one replay computes, rather than a parallel calculation that can drift. Dispatch returns `admitted` when the transport write completes; identity settles on the echo through a channel that did not previously exist for Codex. Waiters are keyed by client message id instead of being shifted off the front of an array by arrival order, and they are cleared on session close and child exit -- previously a timeout was the only thing that ever ended one. `TURN_ID_WAIT_MS` is deleted. It was never reachable on any build measured: `readCodexTurnId` returns non-null on all three, so the 10s wait never fired. The comment justifying it claimed older builds acknowledge before the id exists, which no tested build does. Three comments asserting Codex answers a mid-turn send with `turn already running` are corrected. Their only backing was a test fixture inventing that error string. The correction is factual only -- every changed line in `src/main/runtime/orchestration/` is a comment, and mid-turn delivery is still refused for both providers. Whether that policy is right is a separate question; it was resting on a false premise. Known gap, stated rather than implied: this prevents new collisions and does not repair journals already written with a colliding or phantom key. Those conversations keep duplicating on restore. Repairing them means re-matching persisted submissions against provider history and rewriting `providerItemId` -- which is what `journal-submission-reconciler.ts` is written for, and it still has no production caller. * test(codex): drop the synchronous-accept contract and the colliding `:0` from the integration fakes Three tests in the structured-session integration suites encoded the dispatch contract this branch replaces, and two of them pinned the defect it fixes. They asserted `agentSession.send` answers `dispatchState: 'accepted'` carrying `providerItemId: codex:<thread>:<turn>:0` at send time. That ordinal was never observed; it was stamped on every accepted send, which is exactly the collision this branch removes -- a send coalesced into a running turn is answered with the running turn's id, so two submissions persisted one durable key. The visible failure was a 30s timeout rather than a failed assertion. The fake client advertised no `agent-session.pending-send-result.v1`, and without it the host holds the reply until the send settles: a shim for clients too old to render a pending bubble. The fake provider then echoed the user message with no `clientId`, so nothing could correlate that echo back to the submission, and the wait ran to its own 30s ceiling. Real Codex sends `clientId` on that echo, and the fake now does too, which is what makes it a model of the provider rather than a sketch of one. The identity assertion is kept rather than dropped. Each send now asserts `pending` with no identity at admission, then asserts the submission settles `accepted` at `codex:<thread>:<turn>:0` once the echo lands. Same ordinal, but earned from `identityFor` on the echo -- the key a replay recomputes -- instead of guessed from the turn/start response. Ablated: removing `clientId` from the two echoes leaves both submissions `pending` and fails both assertions, so the assertion is load-bearing and not satisfied by something incidental. Both suites' client fixtures now advertise the capability set the desktop renderer sends in `src/main/ipc/runtime.ts`, which is what these suites mean by a client. The older-client settlement wait keeps its own coverage in `src/main/runtime/rpc/methods/structured-agent-session.test.ts`. `structured-agent-session-runtime-exit.test.ts` asserts `pending` for the same reason; it drives the host directly, so it never took the compatibility path, and what proves delivery there is still the turn the reacquired provider starts. The replay suite's "without dispatching it twice" property is untouched: one `turn/start` call, one replayed ledger row. * fix(codex): preserve unsettled dispatch correlations * test(codex): type the dispatch fixtures instead of asserting over them main's new casting gate (#20367 base) flags type assertions on changed lines. Replace them with checked types: the recording sink already satisfies its interface, both CodexSession fixtures are now annotated and carry real collaborators, the settlement assertion compares whole identities, and the integration helper reads submissions through the host…

pullfrog Bot reviewed Sep 13, 2026

View reviewed changes

Comment thread src/main/ai-vault/session-scanner-service-search.ts Resolved

Jinwoo-H added 6 commits September 13, 2026 19:41

Jinwoo-H force-pushed the session-search-pr3b-wiring branch from 6660355 to 4eea86f Compare September 13, 2026 23:43

Jinwoo-H requested a review from brennanb2025 as a code owner September 13, 2026 23:43

Jinwoo-H changed the base branch from session-search-pr5-contract to main September 13, 2026 23:43

coderabbitai Bot reviewed Sep 13, 2026

View reviewed changes

Comment thread src/main/ai-vault/session-scanner-service-client.ts Resolved

Comment thread src/main/ai-vault/session-scanner-service-entry.ts Resolved

Comment thread src/main/orcad/orcad-command-arguments.ts Resolved

pullfrog Bot reviewed Sep 14, 2026

View reviewed changes

Jinwoo-H added 2 commits September 13, 2026 22:19

fix(ai-vault): recover search indexing and refresh scan roots

f0323b1

fix(ai-vault): defer search refresh policy reads

db397e5

coderabbitai Bot reviewed Sep 14, 2026

View reviewed changes

Comment thread src/main/ai-vault-search/session-search-enablement.ts Resolved

pullfrog Bot reviewed Sep 14, 2026

View reviewed changes

fix(session-search): stabilize paging and host enablement

705a35a

pullfrog Bot reviewed Sep 14, 2026

View reviewed changes

OrcaWin mentioned this pull request Sep 14, 2026

fix(session-search): read oversized numeric file IDs on Windows #20551

Merged

8 tasks done

Jinwoo-H added 2 commits September 13, 2026 23:55

fix(session-search): refresh host roots within full sweeps

100d542

docs(session-search): clarify initial root fallback

9845bef

pullfrog Bot reviewed Sep 14, 2026

View reviewed changes

Jinwoo-H mentioned this pull request Sep 14, 2026

feat(session-search): add panel search and opt-in consent (PR7) #20580

Merged

Jinwoo-H mentioned this pull request Sep 14, 2026

feat(session-history): add local search settings and index controls #20582

Merged

Jinwoo-H merged commit eba56f2 into main Sep 14, 2026
33 checks passed

github-actions Bot mentioned this pull request Sep 17, 2026

Upstream Orca update: v1.4.204 samwooax/samwoo-orca#33

Open

Conversation

Jinwoo-H commented Sep 13, 2026 • edited by github-actions Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

ELI5

What Changed

Why

Deviations from the plan, and why

Linked Issue

Visual Proof

Testing

AI Disclosure

Review

Agent skill upstream boundary

Notes

Checklist

Uh oh!

pullfrog Bot left a comment

Choose a reason for hiding this comment

ℹ️ Index database is created with weaker file permissions than the parse cache it sits beside

ℹ️ A child that faults while the index is enabled stays dead until some later request

Uh oh!

Uh oh!

Jinwoo-H commented Sep 13, 2026

Rebased onto main, base retargeted

Uh oh!

coderabbitai Bot commented Sep 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Reviews paused

Walkthrough

❌ Failed checks (2 warnings)

Uh oh!

coderabbitai Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

pullfrog Bot left a comment

Choose a reason for hiding this comment

Uh oh!

pullfrog Bot left a comment

Choose a reason for hiding this comment

Uh oh!

coderabbitai Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

pullfrog Bot left a comment

Choose a reason for hiding this comment

Uh oh!

pullfrog Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Jinwoo-H commented Sep 14, 2026

Codex review round + follow-up, head 705a35a5a2

Uh oh!

pullfrog Bot left a comment

Choose a reason for hiding this comment

Uh oh!

pullfrog Bot left a comment

Choose a reason for hiding this comment

ℹ️ Nitpicks

Uh oh!

pullfrog Bot Sep 14, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Jinwoo-H commented Sep 13, 2026 •

edited by github-actions Bot

Loading

coderabbitai Bot commented Sep 13, 2026 •

edited

Loading

Codex review round + follow-up, head `705a35a5a2`