* Implement multi-keyword palette matching with evidence-based ranking
Replaces the single-match-per-field scoring with a comprehensive matcher that:
- Validates token coverage across multiple query keywords
- Normalizes Unicode text consistently across all sections
- Classifies matches by quality for cross-section leadership
- Supports evidence-based matching with hidden supporting fields
- Includes typo matching for letter-only words
- Performance-gated against a synthetic corpus of 800+ candidates
Result structure now carries match ranges per field (not per row), quality class, and document rank so sections can compare relative strength. This enables worktree/open-tab/intent section ordering based on match intent rather than hardcoded defaults.
* Improve cmd-j palette selection after deferred query commits
Instead of clearing selection when the deferred query commits,
intelligently select the next available item using the standard
selection logic. Also remove unnecessary array index from React
key generation to prevent spurious re-renders.
* reland(browser): restore CDP-identity cookie-import writes (#14729)
Reverts the revert 3c8410d927 (#14942) to restore the reviewed bf6dc6fcba
tree. The defect that caused that revert is NOT fixed by this commit — it is
fixed in the commits that follow, so the delta a reviewer must scrutinise
stays small instead of hiding inside a 2000-line re-add.
Conflict resolutions, all keep-both:
- browser-cookie-import.ts: two hunks around the zero-import early return.
#14683's undecryptable warning and decryptedCookies.length === 0 condition
are kept alongside the reland's old-client gate and partitionSkippedCookies.
The old-client gate stays above the early return, and so above any mutation.
- en.json: both string sets (#14683's undecryptable copy and partitionSkipped).
- crashpad-capture.test.ts: took HEAD wholesale; unrelated to this ticket.
getStoragePath, and its positive-write assertion moves from cookies.set to the
CDP identity store — adapted, not weakened, and now strictly stronger because
it also asserts cookies.set carries no imported user data. Every decryption
assertion is untouched.
* fix(browser): add registrableFamily, one definition of a cookie family
STA-4300, change 1 of the reland fixes. No behaviour change yet — this only
adds the helper the later commits derive every skip scope from.
Deriving "family" inline in several places is what let the removal scope and
the write set disagree in STA-4090 and STA-4170, so there is exactly one.
The IP check runs on normalizeCookieDomain's OUTPUT, never the raw string.
psl treats an IPv4 literal as a dotted DNS name — psl.parse('127.0.0.1').domain
is '0.1' — and Chromium accepts many spellings of one address. new URL() inside
normalizeCookieDomain canonicalises 127.1 / 2130706433 / 0x7f.1 / 010.0.0.1 and
a trailing dot to a dotted quad first, so isIP() then catches all of them.
Mutation-proved: moving the check ahead of normalisation reddens the five
alternate-spelling cases and nothing else.
Bracketed IPv6 needs its own branch because isIP('[::1]') is 0; without it the
value falls through to psl, which throws, which returns the host — the right
answer for the wrong reason.
Returns null for a bare public suffix: naming `com` as a family would preserve
an entire TLD from removal and silently turn an import into a no-op.
* fix(browser): plan every cookie's fate before any jar mutation
STA-4300, change 2. Adds planImportWrites — pure, no I/O — so the write set and
every removal scope can derive from one value instead of being computed twice.
Not yet wired into the import paths; that is the next commits.
TWO passes, and the second is not optional. Family-atomic skip is a property of
the whole input: with a readable mixed.example row BEFORE an unreadable
sub.mixed.example row, a per-row guard emits the readable one before anything
knows the family will be skipped. Pass 1 classifies and collects the skipped
families; pass 2 re-filters the provisional writes.
Mutation-proved with a faithful one-pass guard (consult skippedFamilies as you
go): the readable-before-unreadable case goes red and the unreadable-before-
readable case still passes. That asymmetry is why both orders are tested and
why only the first is the named detector.
Family closure is at the registrable boundary because that is the boundary the
removal scope actually expands to: importedDomainScopes turns an imported
mixed.example into descendant roots, so a readable apex cookie drags a skipped
subdomain's live session into the removal scope (STA-4300 §2b).
hasUnrepresentableSkip surfaces a skip whose family cannot be named. A family we
cannot name is one we cannot exclude from the removal plan, and clearing a
family we cannot protect is the P0 this ticket exists to stop — so the caller
refuses before mutating rather than proceeding and hoping.
* fix(browser): derive path A's removal scope from the write plan (STA-4300 §2b)
Change 3. importValidatedCookies now plans before it opens the jar, and the
replacement scope and the write set are the SAME array.
bf6dc6fcba filtered replacementDomains per exact cookie
(partition.status !== 'unreadable'). That is not sufficient:
replaceCookiesForImportedDomains expands each imported domain into its
descendant roots, so a readable cookie on mixed.example pulls sub.mixed.example
into the removal scope — and a skipped cookie living there has its session
removed with nothing written back. Same erasure as the P0, different path.
plan.writes is family-closed, and because path A passes the very same array to
replaceCookiesForImportedDomains and to writeImportedCookies, the two sets
cannot drift apart. That is stronger than keeping them in sync: there is only
one set.
Also here, both before any mutation:
- an unrepresentable skip (registrableFamily → null) refuses the import, because
a family we cannot name is one we cannot exclude from the removal scope;
- the old-client gate now keys off plan.skips rather than re-deriving the
condition.
Counters: partitionSkippedCookies is a BREAKDOWN of skippedCookies — the
unreadable rows plus their family-suppressed siblings — added in exactly once,
so totalCookies === importedCookies + skippedCookies keeps holding. Counting it
separately is how a summary silently stops adding up.
Full src/main/browser suite: 69 files, 729 tests, green.
* fix(browser): split path B into scan and emit, and never stage a skip (STA-4300)
Change 4 — this is the commit that fixes the shipped P0.
bf6dc6fcba did:
decryptedCookies.push({ ..., partition }) // write set built HERE
if (partition.status === 'unreadable') { ... continue } // guard AFTER
so an unreadable row discovered late could not retract a sibling already
emitted, while removeTransplantableCookies cleared the ENTIRE jar. The mutation
set was the whole jar and the write set a strict subset of it, which is how a
mixed readable/unreadable source emptied a populated jar and repopulated only
part of it.
Now the row loop SCANS only. Nothing is emitted inside it — not decryptedCookies,
not domainSet, not a staging row, not the imported count. Between scan and emit,
planImportWrites closes the skip over whole registrable families, and emit walks
the plan. Each scanned candidate carries its raw source row because
buildChromiumCookieInsertParams needs it; a record holding only the derived
fields compiles and then silently cannot stage.
Also between scan and emit, both before any mutation:
- an unrepresentable skip refuses the import;
- any skipped family calls disableStaging. A staged image is a whole-database
replacement on the next start, so it cannot express "preserve this family";
main's existing memoryFailed arm then reports restart-fallback-unavailable.
Test contract change, deliberately stronger: "never stages a partitioned row
whose ancestor bit is unreadable" asserted that an image WAS registered and
merely omitted the row. That image would still have erased the preserved family
on replay. It now asserts no image is registered at all — plus a new paired case
proving a no-skip import still stages, so "disable on skip" cannot be
implemented as "disable always" unnoticed.
Honest note on detection: reverting the emit filter currently reddens only the
staging assertion, because every end-to-end fixture in this module still starts
with an EMPTY jar — where clear-then-write-all and clear-then-write-some are
indistinguishable. That is the blind spot that let this ship. The populated-jar
suite in the next commit is what actually detects the erasure.
Full src/main/browser: 69 files, 730 tests, green.
* fix(browser): never remove a family the import declined to write (STA-4300 I2)
Change 5, and the one that makes preservation observable.
removeTransplantableCookies takes preserveFamilies. removableCookieEntries
filters those families out, which keeps them out of the removal plan AND — since
the CDP snapshot is taken from that same list — out of the restore set, so a
preserved coordinate is never submitted to any mutation at all.
When anything is preserved, the bulk clearData path is not used. clearData
removes everything outside excludeOrigins, and its own comment concedes a
rejection may already have emptied part of the jar; a preserved family is
deliberately absent from the snapshot, so a partial delete followed by a
rejection would destroy it with no identity able to restore it. Handing a
dynamically derived preserve list to that primitive cannot be made safe, so a
skip-bearing clear runs the frozen per-coordinate plan — which already excludes
those families — as its primary path instead. Nothing is preserved on an
ordinary import, so that path keeps today's single clearData call unchanged.
New populated-jar suite. Every end-to-end fixture in this module starts with
cookies.get returning [], and against an empty jar "clear then write all" and
"clear then write some" are indistinguishable — which is why four independent
gates missed the P0. These fixtures start populated.
Mutation-proved, and this is the first detector in the change set that catches
the actual erasure rather than a proxy:
- drop the preserved-family filter → 6 of 8 red
- use bulk clearData while preserving → 6 of 8 red, including
"leaves a preserved family untouched", which is the erasure itself
IPv4-literal and single-label host families are covered explicitly: psl reads
127.0.0.1 as the dotted DNS name '0.1', so a wrong family here would fail to
match the preserve set and erase the live loopback session.
Full src/main/browser: 70 files, 738 tests, green.
* test(browser): pin STA-4300 end to end in real Electron, both write paths
Ports the pre-implementation reproduction into the PR. Verified RED against
main's product code and GREEN with the fix, on both paths — I re-ran it both
ways rather than assuming.
Two assertions are INVERTED rather than deleted, and both are now stronger. The
repro proved the defect by showing cookies.set was called WITHOUT a partitionKey;
after the reland the import write path does not touch cookies.set for user data
at all, so seeing the imported cookie there is itself the regression. The
fixture's internal guard is inverted the same way.
Non-vacuity, asserted in-run rather than in a report: ok:true with a nonzero
importedCookies, the importer reaching its terminal step, the source really
carrying its partition fields, and a CONTROL cookie written via CDP *with* a
partitionKey and read back with it — so "partitionKey absent" cannot be confused
with "the oracle cannot see partitions". electronVersion proves Electron ran.
Fixture correction worth recording, because the original reproduction was
invalid on this path and I did not catch it on first read: readJsonCookiePartition
reads a NESTED partitionKey object, but the fixture wrote topLevelSite and
hasCrossSiteAncestor at the entry's top level, where the importer never looks.
The file/paste case therefore failed on main for a fixture-shape reason rather
than for the defect — and its own non-vacuity check validated what the fixture
wrote instead of what the parser reads, which is exactly how a check that looks
rigorous proves nothing. Only the native half was ever a real reproduction.
Partition keys use a schemeful SITE, not an origin: Chromium canonicalises
https://app.example.com to https://example.com, measured via CDP.
* fix(browser): fail closed on lossy cookie identity recovery
* fix(browser): preserve unreadable families before decrypt
* fix(browser): reject malformed cookie partition sites
* fix(browser): validate recovered cookie partition sites
* fix(browser): reject empty JSON partition identities
* fix(browser): fail closed and serialize cookie imports
* fix(browser): reject malformed CDP opaque flags
* fix(browser): roll back outcome-unknown cookie writes
* revert(browser): move import serialization out to STA-4601
Reverts only the concurrency-serialization half of f7c27b71ab so #15030 stays
scoped to the STA-4300 reland. That commit mixed two concerns; this removes one
of them and keeps the other.
REMOVED (moves to STA-4601, a separate pre-existing P1):
- acquireCookieMutationLock / withCookieMutationLock and the mutationLocks map;
clear.ts goes back to withCookieClearLock
- the import-wide lock in path A (mutationOwner on the target, acquire/release
around replace + writes + rollback)
- the widened lock around path B's clear + memory writes
- browser-cookie-import-concurrency.test.ts
KEPT (genuinely STA-4300 scope, not concurrency):
- partitionKeyOpaque handling in readJsonCookiePartition and the CDP snapshot.
An opaque partition key cannot be represented faithfully, so it reads as
unreadable and its family is preserved — exactly the rule this ticket adds.
194e57a628's refinement of that shape stays too.
The concurrent-import interleaving is real and reachable (nothing serialises
imports per partition, and the clear lock is released before the memory writes),
but it predates this change and is not caused or worsened by it. It gets its own
PR and its own review rather than riding a P0 reland whose history is that every
additional fix introduced a new defect.
src/main/browser: 71 files, 772 tests, green. Electron oracle still passes on
both write paths and still goes red against main's product code.
* fix(worktrees): keep retirement tombstones across project and SSH target re-add
Generated workspace names are retired so a name is never reissued onto a cwd
that still holds another workspace's Claude/Codex history. Two re-add paths
lost that record.
STA-4449 (local): retirement was stored only under `repo.id`. Removing a
project deletes that row and re-adding the same path mints a new id, so the
new repo starts with an empty registry. The on-disk backfill normally
re-seeds local repos, but it cannot recover a name whose only surviving
evidence is a Codex rollout JSONL — those are deliberately not scanned — so a
name spent under Codex with its workspace directory gone came back.
STA-4491 (SSH): the second, path-derived copy embedded the SSH target row id.
Row ids are minted fresh on every re-add, so `ssh:ssh-old:...` became
`ssh:ssh-new:...` and `reassignSshTargetId` migrated other carrier state but
not the retirement namespaces.
Keying the store on the namespace instead of `repo.id` was rejected in
`nestWorkspaces`, `worktreeBasePath` and `repo.path`, so a settings toggle
would orphan every retirement at once. `repo.id` therefore stays primary and
the path-derived namespace stays a mirror — a settings toggle loses the
mirror but keeps the repo row, a re-add loses the repo row but keeps the
mirror, and reads union both.
- Mirror local repos into the namespace too, not just remote ones.
- Key the namespace's host half on the SSH endpoint (host+port+username), the
thing that actually decides which filesystem a path lands on, instead of the
target row id. Reads also accept the pre-identity key so an upgrade keeps
tombstones it already wrote, and `reassignSshTargetId` re-keys the rest.
- Cap the namespace map, which by design outlives the repos that wrote it and
so has nothing to prune it per repo.
Endpoint identity is extracted from ssh-target-readoption.ts, which already
compared these fields for exactly the same reason, so re-adoption and
retirement cannot drift apart.
* fix(worktrees): copy shared SSH endpoint retirements instead of moving them
An endpoint identity is not owned by the target row that rotates: nothing
dedupes SSH targets by host|port|username, so a second live target can still
resolve to the same host. Moving the bucket stripped that target's tombstones
and reissued a path whose agent history is still on disk.
Row-id identities stay a move — reassignment leaves nothing pointing at them.
* fix(worktrees): carry retirement mirror across in-place SSH endpoint edits
Config sync rewrites host/port/username on the existing target row and a
runtime-owned target takes a fresh address from every provision, both keeping
the row id. No re-adoption runs, so nothing carried the endpoint-keyed mirror
across and it stranded — strictly worse than the pre-change key, which was the
row id and was invariant under these edits.
Also bound the map after a migration: a retained source bucket grows it, so the
cap has to be applied there too, and compare registries by membership rather
than size so an uncompacted destination cannot trade a folded name for a new
one and read as unchanged.
* fix(worktrees): skip retirement migration for on-demand runtime targets
An on-demand VM is discarded between provisions, so its fresh address reaches an
empty filesystem and a reissued name collides with nothing. Migrating there
would spend names against history that no longer exists, and because each
provision mints another address it would add a namespace bucket per run,
evicting the real tombstones of local and ordinary SSH repos.
* fix(worktrees): stop the namespace cap evicting what a migration just wrote
Two defects with one root cause. Assigning to an existing key leaves it in its
original insertion slot, so a merged destination kept the oldest position and the
trim deleted the bucket it had just enriched. Retained source buckets are older
than the destinations a copy appends, so at the cap the trim removed exactly the
sources the copy existed to keep — silently turning it back into a move. The trim
now exempts the keys the migration wrote or deliberately kept.
Also stop on-demand runtime workspaces writing namespace mirrors at all: each
provision reaches a discarded filesystem under a fresh address, so the entry can
never be read back and only spends a capped slot that a local or SSH project
needs. The repo-id row still records the name for the live session.
* fix(worktrees): re-insert migrated namespaces so the cap cannot undo a migration
Exempting keys from the trim protected them for that one call and no other. A
merged destination keeps its original insertion slot, so it sat at the front of
the eviction queue and the next unrelated retirement write dropped it — losing
both the migrated name and the name the destination already held, on a host that
had just been re-added.
Re-insert what the migration writes instead, the same discipline the ordinary
writer already follows, so insertion order reflects use. That also removes the
exemption, which could otherwise leave the map stuck at twice the cap until one
later write evicted the whole excess at once.
Corrects the runtime-gate comment as well: the mirror is unreadable after the
next provision, not immediately, so a remove/re-add inside one provision is a
real if narrow loss.
* fix(worktrees): refresh a retained namespace source even when its merge adds nothing
Replacing the trim exemption with re-insertion narrowed the protection: the
exemption covered every retained source, the re-insertion only covered sources
whose merge actually wrote. A copy whose destination already held the same names
was then neither re-inserted nor exempt, so the migration's own trim evicted the
shared source bucket ahead of hundreds of untouched ones — losing the tombstones
of a live sibling target still on that endpoint, which is what copying exists to
prevent.
A move's destination gets the same treatment: deleting the source makes it the
only remaining copy, so it has been used. Both are order-only and deliberately do
not set the changed flag, keeping an import that moved nothing from scheduling a
save.
* fix(mobile-ios): pin fastlane and gate the Fastfile in CI
The ios-distribute job failed on every run from 2026-08-10 to 2026-08-13
because distribute_testflight passed distribute_only without app_platform,
so pilot fell through to an interactive platform prompt on ubuntu. No CI
check loads the Fastfile, so external testers got nothing for six days.
- Pin fastlane 2.238.0 and commit mobile/Gemfile.lock so ios-build (macos)
and ios-distribute (ubuntu) cannot resolve different versions ~25 minutes
apart. Fixes the Gemfile comment's dead mobile-build.yml reference.
- Add a Fastfile smoke check (bundle exec fastlane lanes) plus a static
contract test for the TestFlight lane arguments to Mobile Checks.
- Set reject_build_waiting_for_review so a superseded same-train build in
beta review stops blocking the submission.
* fix(mobile-ios): install the pinned Gemfile.lock in frozen mode
Without frozen, a lockfile that drifts from the Gemfile is silently
re-resolved per job, which is the version split the pin exists to prevent.
* test(mobile-ios): anchor the TestFlight argument contract against an empty selection
* chore(mobile-ios): canonicalize the lockfile platforms
Bundler's own normalization drops arm64-darwin-25 as redundant with the
versionless arm64-darwin, and the ubuntu runners resolve x86_64-linux-gnu.
* fix(native-chat): enforce each pending send's own boundary in glue matching
Glue matching filtered candidate rows against the OLDEST still-open send and
then matched the entire open queue against them. A prompt queued after a glued
row landed could therefore be judged "already delivered" by that older row and
pruned — the queued prompt disappeared with no bubble and no transcript turn.
Each send now carries its own transcript boundary into the match:
`gluedCandidateRows` tags every candidate row with the set of pending indices
it actually landed after, and the matcher stops a run at the first send the row
predates rather than skipping over it (adjacency is what makes a row glue).
Exact single matches still belong to the occurrence path, unchanged.
`native-chat-pending.ts` sat at 299 of its 300 effective-line budget, so the
slash-command marker cache — a separate rule that never took part in pending
pruning — moves verbatim to `native-chat-command-marker.ts`. Pure move: no
behavior change, imports only. (max-lines is never bumped or disabled.)
Refs STA-4477. Original PR #14663.
* test(native-chat): cover the glue adjacency break and unmask the render path
The `break` on a send the row cannot represent is the fix's central semantic
choice, and swapping it for `continue` was passing the whole suite: nothing
exercised a queue whose middle send is unrepresentable. Add that case.
The mixed-age case also asserted both call sites in one `it`, so a prune-path
failure masked the render-path assertion — and the render path is the one that
makes a queued bubble visually vanish. Split it.
Skip the per-send boundary scans when fewer than two sends are open: the glue
matcher already returns nothing there, so a lone queued echo was walking the
transcript twice per render for a discarded result.
* fix(native-chat): migrate the live-session benchmark off the renamed glue exports
Renaming the glue matcher's exports left this caller behind, and it crashed at
runtime after printing six result rows:
TypeError: matchingNativeChatUserTexts is not a function
No gate caught it. config/scripts/** is in no tsconfig include and the file is
not a *.test.ts, so neither typecheck nor vitest ever loads it.
The empty-pending arm passes no pending sends, so the matcher takes its
empty-queue exit without ever reading the rows — which is also why the renderer
skips candidate-row construction entirely in that case. Escaping the row scan
directly keeps what this arm actually measures identical to before, rather than
fabricating per-row boundary sets that no production path builds.
* refactor(terminal): redesign quick command dialog with expanded layout a
- Enlarge dialog to 52rem width and add scrollable content area for improved editing experience
- Restructure textarea with header (label, status badge) and footer (hints, controls)
- Compact action toggle to use shorter labels with grid layout
- Move append enter switch to textarea footer (compact mode) for terminal commands
- Add scope summary to Advanced toggle when collapsed for quick reference
- Update dialog description and add contextual hints for user guidance
* fix(terminal): restore defaultAdvancedOpen on quick command dialog
Settings still opens the Advanced section from settings; the redesign dropped the prop and failed typecheck.
* Improve accessibility of terminal quick command dialog
- Add inert attribute to prevent keyboard/screen reader access to hidden advanced section
- Add aria-label to textarea for clearer form field labeling
- Extract label text to variable to avoid duplication and ensure consistency
* refactor: remove status badge from quick command header
Simplifies the dialog header layout by removing the "sent to agent" /
"runs in terminal" badge and its associated translation strings.
* fix(codex): stop a transient filesystem error from logging out the active account
A single unreadable read of a managed Codex home's ownership marker cleared the
user's active account selection, permanently. On Windows any exclusive lock —
Defender real-time scanning, a backup agent, a sync client — makes every read of
that marker fail with EBUSY, and the background rate-limit poll runs every 15
minutes plus once at every app start.
Root cause: the ownership gate answered two very different questions through one
channel. "This home is not ours" (a successful observation that failed a trust
check) and "we could not read it" both surfaced as a throw, which the caller
flattened to null, which three call sites took as proof the home was
untrustworthy and wrote activeCodexManagedAccountId: null.
Refusing to USE an unverified home is correct. Erasing the user's account
selection because a file was briefly locked is not.
The gate now returns a tri-state verdict. `untrusted` comes only from a proven
trust failure or a definitive ENOENT/ENOTDIR where absence is itself the
verdict; every other filesystem exception is `indeterminate`. Only `untrusted`
may touch persisted state.
Because `null` already meant "fall through to the system default" on both the
launch and poll paths, not-clearing on its own would have run a DIFFERENT
account behind a UI still showing the selected one. So the refusal needed real
channels rather than a sentinel:
- the poll returns an explicit skip; returning null would not have skipped at
all, since the fetcher maps null to ~/.codex and would have spawned a
token-refreshing app-server inside the user's real credential home
- pane launch throws a typed temporary-unavailability error that both PTY
implementations convert into a clean refusal with a retry message, including
the re-resolution after the async auth-readiness wait
- automatic session resume resolves the selected home eagerly, so an unreadable
account can no longer be silently replaced by another one in the ranking
- config-sync status reports a distinct managed-home-unavailable stall instead
of "synced", with a bounded renderer retry so it clears on its own
Also fixes the ticket's second symptom. The status bar's Sign in button called a
re-auth that captured the selection before login and restored it after, so
re-authenticating a deselected account restored `null` — a successful login that
left the account inactive, with no success toast to distinguish it from failure.
It now activates the account it just signed in, but only when the pre-login
selection was empty, so it cannot silently switch accounts for multi-account
users, and it runs the same restart prompt an explicit switch does.
No retry or grace window inside the synchronous gate: it runs on the Electron
main process in a loop over accounts, so a sleep there would freeze the UI.
Recovery is simply the next readable evaluation.
The WSL lane has the same class of defect, including one path that deletes a
credential mirror. It is pre-existing, unreachable from these host code paths,
and deliberately left for its own change; the host clearing sites cannot reach a
WSL account because getSelfContainedManagedHostAccount excludes them.
Fixes STA-4422
* test(codex): cover pending reset home ownership
The backfill guard tested repo.connectionId, but a runtime-owned repo
carries executionHostId with no connectionId, so it read as local. The
scan then walked this machine's workspace and agent-transcript
directories and filed the result under the runtime host's namespace —
retiring names never used there while missing the ones that were.
Guard on the execution host id instead. Ongoing retirement was already
correct for these repos; only the one-time historical seed was wrong.
* fix(mobile-native-chat): reland glued pending retirement without the two revert causes
Relands #14665 (reverted by #14819). #14665 retired mobile pending bubbles when
two fast sends landed as one transcript row, but shipped two regressions; both
are fixed here rather than re-applied and hoped for.
1. A rejected send restored a TRIMMED composer. #14665 reassigned `text` to
`text.trimEnd()` at the top of `sendMessage` and then used that one value for
both the bytes on the wire and the composer restore, so a rejection put back
less than the user typed. The draft and the payload are now separate values:
`draftText` is what the user typed and is what `clearDraftForSend` /
`restoreRejectedDraft` see; only the transported `text` is trimmed.
2. Sends issued during hydration were stranded forever. #14665 persisted
`glueBaselineTrusted: false` on any send captured while the transcript was
still loading and never cleared it, so that send could never retire and stood
as a permanent glue barrier for its neighbours. A hydration-time baseline is
now a placeholder (`baselineResolved: false`) that the first authoritative
read rebases onto real rows, ordinals included, instead of a permanent
disqualification. That is STA-4492.
The intended behavior is unchanged: one transcript user turn retires a run of
2+ adjacent text-only pending sends only when it exactly spells their normalized
concatenation, every send is bounded by its OWN transcript tail, and exact
landings, image echoes and unresolved tails stay barriers.
No wire change: `baselineResolved` and the baseline tail are client-local React
state in `pendingBySession` and are never exchanged with a host. The only
client->host difference is trailing whitespace no longer being written onto the
agent's input line, over the existing `terminal.send` params.
Refs STA-4482, STA-4492. Original PR #14665, revert #14819.
* fix(mobile-native-chat): let the untrimmed draft reach the send seam
The composer sent `value.trimEnd()`, so the raw draft never reached
`sendMessage` and a rejected send still handed back a trimmed composer —
the split of `draftText` from the transported `text` had nothing to
restore. Pass the draft through; the seam already owns the wire trim.
Also pins the array-identity contract of
`retireLandedMobileNativeChatPending`: the drafts effect early-outs on
`next === current`, and nothing tested it.
* docs(mobile-native-chat): name the hydration rebase's residual ambiguity
* fix(mobile-native-chat): stop the hydration rebase stranding a send on its own echo
Rebasing recounted the send's ordinal against the first authoritative read.
That read can already carry the send's own echo — a re-subscribe after a tab
switch or reconnect returns whatever exists now — so the ordinal landed one
past anything the transcript could supply. The bubble never cleared, it stayed
a live segment at the head of its run so no later pair could glue either, and
`earlierOutstanding` carried the inflation onto the next send of the same text.
Only the tail needs recovering; the ordinal was already counted against an
empty transcript, which is right for "no history was known". A caption-less
image echo keeps its captured tail, since it counts turns after it.
`baselineResolved` also has to mean "captured against a settled read", not
merely "not loading": a read that failed hands back an empty list that reads as
an empty conversation, and the null tail then let any row the successful read
finally brought glue-retire those sends.
* test(mobile-native-chat): pin that a resolved hydration send leaves its run glue-capable
A held send sits as a live segment at the head of its run, so the cursor can
never reach a later pair — the stuck bubble takes the whole feature down with
it. Goes red against the ordinal recount.
* fix(mobile-native-chat): pin an image echo that captured no tail, and require the settled flag
A caption-less image echo keeps its captured tail because it counts image turns
after it — but a send issued before any history was known captured null, which
counts from the top of the transcript. An old image turn then claimed the send
and bound the user's fresh photo to it, leaving the just-sent turn with no
preview. A null tail is not a boundary worth preserving, so pin those too.
`transcriptSettled` was optional and defaulted to the gate it replaced, so any
caller that omitted it silently got the pre-fix behaviour. Required now, and
threaded through every harness.
* fix(mobile-native-chat): stop an unbounded send claiming an image turn already in the read
The image-preview pass runs before the rebase, so a send captured with no
boundary matched any image turn the settled read carried — binding the user's
freshly attached photo to an old one and retiring the bubble through
landedImagePendingIds, which short-circuits the retirement path entirely.
Pinning the tail in the rebase could not help: the claim was already made.
Such an entry now waits one tick and claims against a real tail.
* fix(mobile-native-chat): never move a boundary the send already captured
An unsettled read still shows this session's own retained history — a reconnect
or a failed read keeps the conversation on screen rather than blanking it — so
sends made across one already own a correct tail. The rebase overwrote it with
the tail of the read that followed, which sits at or after their own glued row,
so `turn.index <= segment.tail` rejected every turn and the pair stayed queued
for the session, blocking every later pair in the run. Pin only a send that
captured no tail at all.
A captioned image echo is now left alone entirely: it binds its preview by an
ordinal counted over the whole transcript, so supplying a tail without
recounting left it matching nothing, forever.
* fix(mobile-native-chat): supply a boundary only to a text-bearing send
An image echo reconciles by counting turns AFTER its tail and has no other
retirement path, so the tail supplied from a read that already carried its own
echo excluded the very row it was waiting for: the "Queued" photo bubble stuck
for the life of the session and the transcript row rendered as bare marker text
with no photo. A regression against main, and against the earlier revision of
this fix that pinned only captioned echoes.
The glue matcher is the only consumer a supplied tail helps. Everything that
reconciles relative to its own tail keeps whatever it captured.
* fix(mobile-native-chat): stop one unmatchable send freezing glue for the session
The match cursor only advanced on a hit, so a head that could never match —
a pair whose glued row arrived with the read, or a send the count pass claimed
against an older row — froze the run behind it and every later rapid pair
became permanently unretirable. Two cases previously disclosed as bounded were
not bounded at all. Slide past a non-matching head, keeping the cursor
monotonic so a later turn can never take a send an earlier one claimed.
The slide widens the search, so a span cap keeps the work linear in the run
length instead of quadratic; the existing budget test now asserts that bound
rather than the old one it silently broke. Re-fuzzed at 250k seeds: the
boundary guarantee still holds.
Also corrects a comment that claimed the preview-pass filter made a photo claim
against a real tail. It does not — an image echo keeps whatever tail it
captured, so a caption-less photo can still bind to an older photo turn, as on
main.
* fix(mobile-native-chat): stop the span cap stranding a long glued run
Capping each match attempt at 8 segments did not truncate a longer glue, it
rejected it outright: a row spelling 9+ sends exhausted the loop without
reaching the end of the text and returned zero, so none of the nine retired —
and each stuck send then inflated `earlierOutstanding` for the next send of the
same text. Nothing bounds how many sends pile onto the agent's input line;
accumulation ends when the agent accepts input again, not at any fixed count.
One inspection budget now covers the whole slide instead. The first attempt
spans the entire run and always fits, so a genuine glue is never truncated;
only a run of identical prefix-matching sends can exhaust the budget, which is
exactly the case that should be cheap. The in-flight attempt may overshoot the
remainder — that is what makes the guarantee hold — so the budget test asserts
the real ceiling. Re-fuzzed at 250k seeds with runs past the budget.
The keydown that exits a CJK composition carries isComposing: true (UI Events
3.6.5, row 5) and, when the IME is processing key input, keyCode 229 (7.3.1).
Two handlers acted on it:
- right-panel-comment-composer: Cmd/Ctrl+Enter posted the comment while the
last syllable was still composing, so it went out truncated.
- RichMarkdownSearchBar: Enter ran replace-current, mutating the document from
a keystroke aimed at the candidate list; Escape closed the bar instead of
letting the IME cancel the composition. Same in the find field.
Guard all three with the existing isImeCompositionKeyDown helper, matching the
rename and title inputs already on it. The held modifier does not change
ownership: a composing Ctrl+Enter is still the IME's keydown, which is why
useImeEnterGestureOwnership also owns it and only lets the post-compositionend
redispatch chord through.
Co-authored-by: BaeTab <bhwoo48@gmail.com>
Two ways a terminal composition went wrong, both from state that was not
scoped to the session it belonged to.
The route called preventDefault() before checking whether it owned the
session. The patched xterm treats that cancellation as "someone else will
deliver this" and skips its own triggerDataEvent, so a route installed
mid-composition — the connection effect re-runs, a reconnect swaps the
transport, StrictMode remounts — suppressed the insertion and then returned
without delivering anything. The commit vanished. Ownership is now decided
first; preventDefault stays for sessions the route does own, including the
ones it deliberately drops after a transport swap, since that drop is its
decision to make.
Pending-composition state was a bare per-element count, so a waiter could
only ask "is anything composing", not "is what I was waiting for still
composing". A composition the user starts after pressing Enter is behind
that Enter, not in front of it, but it kept the count non-zero and held the
newline anyway — `한` Enter `글` reaching the terminal as `한글\n`. The count
is now reference-counted per session id, and the deferred send snapshots the
sessions open when it starts and waits only for those. Reference counts
rather than a set, so two overlapping routes owning the same session cannot
clear each other's pending state.
Co-authored-by: yeongjunyoo <47925973+yeongjunyoo@users.noreply.github.com>
FolderWorkspacePathStatus is cast, not decoded, off the runtime RPC wire --
runtime-rpc-envelope declares result: z.unknown(), so unwrapRuntimeRpcResult hands
back whatever the host sent. Both title and description switch on status.reason with
no runtime guard, so a newer host publishing a fifth reason matched nothing and
returned undefined. FolderPathStatusIndicator's `!title` check then dropped the whole
indicator, and a broken folder workspace rendered as healthy -- worse than the blank
toast #15002 fixed, because there the warning was empty and here it is gone.
Guard before each switch, the shape #15002 landed. A default: arm is not available:
the type-aware config sets allowDefaultCaseForExhaustiveSwitch:false and rejects one
with switch-exhaustiveness-check.
Extract that guard into isHandledWireDiscriminant instead of hand-writing a third and
fourth copy, and move #15002's two bespoke guards onto it. It takes unknown and checks
typeof before Object.hasOwn -- hasOwn coerces its key, so a host that widened the field
to an array sends ['missing'], which a hasOwn-only guard admits before the switch drops
it straight back out. That was the P1 found in review on #15002; one implementation
makes it structural instead of tribal.
An unrecognized reason gets its own copy rather than reusing 'unavailable'. The
unavailable remedy -- "Check the runtime or SSH connection and try again" -- is a false
lead here: the host did check and reported the folder unusable, so retrying and
inspecting a healthy connection wastes the user's time. Update Orca is the real remedy.
Adding a fifth reason still fails typecheck in two places: TS2741 on the Record and
TS2366 plus switch-exhaustiveness-check on both switches.
* chore: ignore worktrees directory
* fix(cli): relativize absolute POSIX paths against UNC worktree roots in WSL
* fix(cli): prevent double-prefixing UNC paths in WSL path normalization
* fix(cli): gate the WSL path rewrite on a UNC worktree root
WSL_DISTRO_NAME is also set for a plain Linux CLI inside the distro, where
worktree roots are POSIX; prefixing there stranded every absolute path.
Rewrite only when the root really is a WSL UNC path, and cover the legacy
wsl$ alias, cross-distro paths, and the non-WSL case.
* test(cli): pin WSL_DISTRO_NAME absent for the whole file-path suite
Contributors run this suite inside WSL, where the inherited distro name
would flip the rewrite on for every POSIX-root case.
* fix(cli): never rewrite a Linux path that contains a backslash
Backslash is a legal Linux filename character but a separator once the
path reads as UNC, so `a\b.ts` relativized to `a/b.ts` — a different
file. Such a path has no UNC spelling; let it fail the match instead.
* test(cli): pin the WSL rewrite's negative space
Sibling-prefix roots, Linux-tail case sensitivity, and Windows
drive-letter workspaces all passed only by construction.
* test(cli): pin the distro-case fold from the CLI side
The negative-only case passed identically with the fold broken.
* fix(cli): name the WSL distro from the invocation cwd when the env is absent
WSL_DISTRO_NAME only reaches the CLI if interop forwards it across the
PowerShell bridge, which nothing in the launcher guarantees. ORCA_CLI_CWD
is set explicitly and its UNC form already names the distro.
* test(cli): match the launcher's real cwd spelling and fix an over-claim
wslpath -w emits a backslash UNC path; the fallback test now uses that
shape. The aliasing test's comment described a state the || guard makes
unreachable.
* refactor(cli): spell the WSL rewrite with the shared toWindowsWslPath helper
src/shared/wsl-paths.ts already owns "absolute Linux path in a known distro
-> its Windows form" and has five production callers; the handler hand-rolled
a fourth copy of the UNC template. Behavior is identical under the UNC-root
guard, and passing distro as a real argument makes the null check a compile
error rather than an untested branch.
* test(cli): drop a WSL case that pins the guard shape and kills no mutant
Deleting the distro null check left the case green — it asserts the same
passthrough as 'does not rewrite when the CLI is not running under WSL'. The
check is now enforced by the compiler instead.
* chore: keep WSL path fix scoped
---------
Co-authored-by: Brennan Benson <79079362+brennanb2025@users.noreply.github.com>
* fix(terminal): render the covered row tail inside the IME preedit overlay
Closes#12545.
Composing mid-line hid the character at the cursor for the whole composition.
The preedit overlay is an opaque box anchored to the cursor cell, and nothing
reaches the pty while composing, so those cells still held their characters —
the box simply covered them.
`CompositionHelper` now draws the rest of the row after the preedit inside the
view, so the composition reads as inserted text pushing the tail right. Four
details come with it:
- The view is start-anchored while it carries a tail, so the preedit stays put
and the pushed tail clips at the right edge; alone, `rtl` still keeps a long
preedit's end in view.
- It is themed from `options.theme` instead of the stock `#000`/`#FFF`, with any
alpha dropped — the view masks the cells it draws over, so a see-through
background would re-expose the very characters the tail stands in for.
- The helper textarea syncs to the preedit's own bounds, so IME candidate
dialogs anchor to the composing text rather than past the rendered tail.
- A TUI can repaint the row under an open composition, so
`updateCompositionElements` — which already runs on every render — re-reads
the remainder and re-renders on change. A string compare adds no layout read.
The tail is read with an explicit end column: the cacheable form of
`translateToString` arms the line string cache's self-renewing idle-clear timer,
and the composition path must own no timers.
Geometry is not the cause. Two mature reference terminal implementations compose
marked text into the grid rather than into a floating box, and both still blank
the cells under it — one of them literally substitutes the marked characters
into the row's character array before rasterizing. Moving off the overlay would
not have fixed this report; rendering the covered tail is what does.
The e2e arm asserts the invariant an opaque overlay owes the grid: it must
render every committed cell its bounding rect covers. That is measured from the
real rect against the real cell grid, so it fails on the unfixed build with
`covers "하" / renders "가"`.
Known limitation: the rendered tail is plain-styled while composing (theme
foreground on theme background, no per-cell colors); colors return on commit.
This is inherent to the overlay, and drawing the preedit into the cell renderer
instead would be a far larger change.
Co-authored-by: rayim <rayim@fxy.global>
* test(e2e): assert the occlusion invariant, not the runner's cell width
CI covered four columns where this machine covers two — 34.4px over an 8.43px
grid against 12.3px over an 8px grid — so pinning the covered text verbatim
pinned the font metrics rather than the behaviour. Assert instead that every
committed cell the overlay covers appears in what it draws, which is the actual
invariant and holds at any cell width.
Still fails against main: covers "하" / renders "가".
* fix(terminal): keep the rendered tail's spacing on the grid
The composition view is white-space: nowrap, which collapses runs of spaces
exactly like normal — it only suppresses wrapping. So a committed tail carrying
padding drew its trailing glyph cells left of where the grid has them: measured
in Chromium with xterm's own rule, twenty spaces plus a border rendered two
cells wide instead of twenty-one.
The visible case is Orca's most common IME context — composing inside an agent
TUI input box, where the row is a prompt, padding, then a real border glyph the
trim cannot drop. A stray border appeared a cell after the preedit while the
real one stayed put.
xterm sets white-space: pre on its grid rows for this reason; the view was only
nowrap-safe while it held preedit text alone.
The existing fixtures are all space-free, and the e2e invariant is that the
overlay renders everything it covers — collapsing makes it cover less, so both
stayed green. Pinned with a padded-row fixture.
---------
Co-authored-by: rayim <rayim@fxy.global>
* fix(github): fail closed when the SSH git provider is gone
getCurrentHeadOid and probeTrackedUpstreamBranches only routed through the
SSH provider when one was registered. With connectionId set but the provider
unregistered (dropped connection, not yet reattached) they fell through to
client-side git with cwd pointing at the remote repoPath — on a machine with
a same-named local path that silently answers for the wrong repository.
getCurrentHeadOid feeds shouldHideMergedImplicitPR, so a wrong OID changes
which PR the UI attributes to a worktree.
Both now take their existing unknown path (null / probeFailed) instead,
matching repo-default-branch.ts. Local and WSL routing is unchanged.
* fix(github): preserve PR state when SSH probes fail
* fix(github): keep failed SSH discovery unverifiable
* fix(github): propagate SSH identity failures
* fix(github): scope verified SSH identity probes
* test(github): preserve tolerant resolver calls
* fix(github): preserve indeterminate auth discovery
* fix(github): isolate SSH repository probe generations
* test(github): expose SSH probe generation in mocks
* fix(ssh): stop reporting a confirmed kill when the SSH provider is gone
A detached relay PTY is designed to outlive the provider that addressed it
(it ignores SIGHUP and ships with an unlimited grace), so "the SSH provider
is no longer registered" is lost contact, never evidence the remote process
stopped. Both stop primitives in the PTY controller returned `true` from
that branch, and every caller downstream reported the fabricated success:
the CLI printed "PTY killed.", worker-stop settled the dispatch as stopped,
and — because the stop "succeeded" — the unstopped-PTY gate never ran, so
worktree removal walked straight past a live remote agent.
`kill`/`stopAndWait` now still tombstone the local lease but report an
unconfirmed stop and record why, using the three-verdict vocabulary the
worktree teardown gate already spoke (`live` / `unverifiable` / `exited`),
promoted out of that module into `src/shared/pty-liveness-verdict.ts`.
The close receipt, the CLI wording, worker-stop and the removal gate all
read that verdict instead of inferring an exit from silence.
The same rule fixes the mirror-image defect: the aggregate inventory only
enumerates registered providers, so a dropped relay clears `connected` for
every remote PTY at once. The sweep now separates the provider answering
"absent" (an exit) from no provider being able to answer (lost contact), so
worker-stop stops claiming `exited` from a disconnect.
The `connected` wire field is unchanged in meaning and shape.
* fix(orchestration): apply the same honesty to the federation stop path
The federation host runs its own copy of the worker observation and stop
logic, with the same two defects: `inspectRemoteAttachment` read a dropped
relay's `connected: false` as `exited`, and `federationStop` settled the
dispatch as stopped from a close it never confirmed — relaying a fabricated
success all the way home to the coordinator.
Two guards also had to move so the honest verdict does not become a new
refusal. `federationRead` gated on `status !== 'running'`, which would have
rejected a connected terminal the moment a stop lost contact with it; it now
gates on `status === 'exited'`, which is equivalent for every pre-existing
status given the two guards beside it. Local `workerStop` likewise still
attempts the close when the verdict is `unverifiable` — losing contact is a
reason to report the outcome honestly, never a reason to stop trying.
The show observations now carry the reason alongside the status, so a bare
`unverifiable` is actionable. Both are new optional fields.
* fix(ssh): preserve unconfirmed stop verdicts across consumers
* fix(ssh): use canonical live verdict wording
* fix(ssh): refuse wrong-host teardown verification
* test(orchestration): confirm worker release teardown
* fix(orchestration): negotiate honest worker stop receipts
* fix(agent-teams): fence uncertain teammate respawns
* fix(ssh): avoid duplicate missing-provider teardown
* fix(orchestration): preserve archives across release retries
* fix(ssh): preserve verdicts across synthetic kill exits
* fix(ssh): preserve liveness evidence across teardown
* fix(agent-teams): replace panes only after confirmed stop
* fix(ssh): distinguish host exits from relay loss
* fix(ssh): narrow concurrent inventory verdicts
* fix(orchestration): serve archives after uncertain release
* fix(orchestration): expose unverifiable read liveness
* test(ssh): align liveness assertions with verdicts
* fix(ssh): preserve host scope across inventory failures
Descendants of pinned parents now appear in the Pinned section without individual pins. When an ancestor's pin state changes, reveal the active descendant to maintain focus and visibility.
* fix(mobile): decide terminal preedit from the marked-text range, not a script table
The live terminal capture field decided what to withhold from the PTY with a
Unicode-block allowlist (Hangul jamo and syllables) and held exactly one trailing
code point. Kana and kanji are not in the table, so a Japanese reading streamed to
the PTY one fragment at a time and was repaired afterwards with DEL bytes (#7427).
A code-point table cannot work, and the counterexample is not exotic: Chinese
pinyin preedit is plain ASCII, and a Japanese romaji reading is one code point on
the first keystroke and three on the fourth. Preedit is a property of the FIELD,
not of the characters in it, so the only signal that identifies it is the text
system's marked-text range. That is what a reference terminal implementation uses
on every platform it supports - `hasMarkedText` there, the input-method context's
composing state elsewhere - and neither one classifies code points anywhere in the
input path.
So the mirror now takes the marked-text report per change and holds the whole
preedit region, whatever its length or script:
- Subscribe the capture field to `onChange`, not `onChangeText`; only the raw
native event carries the report at all.
- A reported preedit is held entire and is never committed by the settle timer,
because preedit is not text yet. Explicit boundaries still flush it.
- `isTerminalLiveHangulCodePoint` and its four ranges are deleted.
iOS reports the range but React Native drops it before JS, so the pinned patch
forwards `markedTextRange` into the change payload. It is three hunks and it
compiles because the app already sets `buildReactNativeFromSource` for iOS. The
same idea was proposed in #11450, which is where the patch comes from.
Android has no marked-text report in React Native at all, and a Kotlin patch would
not help: Android consumes the prebuilt react-android artifact, so node_modules
sources are never compiled. Until the report exists there, the fallback holds the
trailing non-ASCII run. It enumerates nothing, it covers kana, kanji and Hangul,
and ASCII keeps its zero-latency echo - but it cannot see an ASCII preedit, so
Chinese pinyin on Android still leaks its reading. Only a report fixes that.
Not-tested: no physical device or emulator was available, so no real IME drove
this path. Japanese, Chinese and Korean composition are covered at the model and
hook level only, and the iOS patch has not been compiled.
Co-authored-by: Brennan Benson <brennanb2025@users.noreply.github.com>
* fix(mobile): bound the fallback hold to text the pty has not received
The no-report branch walked the trailing non-ASCII run over the whole field and
ignored stableLength, unlike the reported branch directly above it. So after a
settle-timer commit the next keystroke re-held everything already delivered and
the caller erased it with DEL and retyped it — a nine-character Cyrillic word
cost a DEL per already-sent character, and for the 300ms before the re-send the
held text was the only copy, so a blur or reconnect destroyed characters the pty
already had.
Bound it the way the reported branch is bounded. Pinned by a test that drives a
settle commit between every keystroke and asserts no DEL reaches the wire.
---------
Co-authored-by: Brennan Benson <brennanb2025@users.noreply.github.com>
* reland: portable startup-shell dialect, with the two revert causes fixed
Relands #14863 (reverted by #14975) with fixes for both regressions the
revert cited.
1. History GC deleted folder-workspace shell history. The live set was built
from `getAllWorktreeMeta()` alone, but a folder workspace's PTY carries
`folder:<id>` as its worktree id, so every live folder workspace looked
orphaned. `getKnownWorktreeIdsForHistoryGc` now unions in
`getFolderWorkspaces()`. Both consumers — the history-directory prune and
the fish-history sweep — read that one set, so the fix covers bash, zsh and
fish history alike. The directory prune had this gap since #1524; #14863
only widened its blast radius to fish files.
2. A copied Codex resume command aborted under `set -u`. Its leading clear
statement has to test `$fish_pid`, and that unbound expansion takes the
whole line — including the agent launch — down with it. Copied text runs in
a shell Orca never spawned, so nothing can seed that variable first. The
removal now rides on the agent itself as `env -u`, which needs no shell
syntax and no expansion. Verified byte-identical under `set -u` in sh,
bash, zsh, dash, ksh and fish.
`env` cannot run the `cd` builtin, and a child `cd` would not move the
agent, so the prefix is placed on the agent rather than on the whole
`cd … && agent` chain. cmd and PowerShell have no nounset hazard and keep
their clear ahead of the `cd`, which preserves `cd … && agent` — a failed
`cd` still cannot launch the agent in the wrong directory.
* fix(history-gc): stop three more paths from deleting live shell history
Found by adversarial review of the reland. All three are the same class as
the bug that caused the revert: a live set that is missing a category of
real workspace, so the GC reads it as orphaned.
1. Profiles. The history root is `userData/terminal-history`, which has no
profile segment, but the Store the GC consults is per-profile. So after a
profile switch the live set condemned every other profile's history — and
fish history, which lands in the user's own fish data dir, is shared by
every profile on the machine. The live set now unions in the inactive
profiles' worktrees and folder workspaces, read from their data files. A
profile whose ids cannot be read reports the empty set rather than one
that condemns real history.
2. No empty-set guard on the tree scan. `sweepOrphanedFishHistoryFiles`
refuses an empty live set because it cannot be told apart from a store
that failed to hydrate; the directory scan, which deletes more, had no
such guard. A store that fell back to default state would have taken
every worktree's bash and zsh history with it, across all roots including
WSL. Four existing tests passed `new Set()` and relied on "empty means
everything is orphaned" — exactly the behavior being removed — so they
now pass a real live set.
3. Relay fish history. The relay isolates its history tree under its own
root but wrote fish history into the shared fish data dir under the
desktop naming, keyed by the CLIENT's worktree ids. On a machine running
both Orca and a relay host, the desktop sweep deleted remote sessions'
history once it went stale. Relay files are now `orca_relay_<hash>`,
which the sweep's pattern deliberately does not match; the relay still
deletes them by exact name when the worktree goes away.
* fix(resume): enforce the env-removal invariants instead of documenting them
Both found by adversarial review; both were unreachable from today's callers
and silent if reached, which is exactly how they would survive to a caller
that does reach them.
- A pinned CODEX_HOME and the removal named the same variable, and `env -u`
strips what the assignment just set — so the agent would have resumed
against the real home and not found the session. The removal list now
excludes any name the prefix pins, keeping the assignment authoritative as
the old `clear…; CODEX_HOME=x agent` ordering did. Same fix in the git-bash
twin. The PowerShell branch already clears before it assigns, so it was
never affected.
- Placement was keyed on the platform while the grammar it selects is keyed
on the shell, so `platform: 'linux'` with `shell: 'powershell'` emitted
POSIX `env -u` into a PowerShell line. PowerShell now routes to the
PowerShell builder whatever the host, and the POSIX/cmd split below asks
the shell rather than the platform.
* fix(skills): keep an unanswered skill root's last known skills instead of reporting none
An aborted or shed root scan degraded to `{skills: [], unavailable: true}`. Every
consumer derives "installed" from the skill list, so an unreadable root read as
proof the skill was gone and an already-installed skill offered Install again.
- discovery: retain the last answered scan per root (5 min, LRU-bounded, dropped
on install/update invalidation and when a root answers as absent) and serve it
when a later scan goes unavailable.
- source inventory: an unanswered root reports `exists: true`, so check
`skippedReason` first rather than presenting it as a successful scan.
- useInstalledAgentSkills: when an in-scope root did not answer and the skill was
not found, say the status may be incomplete instead of a bare "Not installed".
* fix(skills): do not let install verification accept an unanswered root's retained scan
Retention makes discovery serve a stalled root's last completed scan, which is the
state before an install wrote. Verification read that as proof, so reinstalling a
skill into a root that stalled could report success without reading what it wrote —
turning a retryable false negative into a false positive.
A match now counts only when a root that actually answered reached the skill, so a
symlinked placement co-owned by a healthy root still verifies.
The chord held for a live composition waits with `fallbackMs: null`, so nothing
but compositionend can end it. `sendTerminalInputAfterComposition` returned
void, so nobody could stop it either: the two listeners it puts on the terminal
element outlived the pane, and a later composition on that element flushed the
stale chord.
Return a disposer from the helper and put a sender in front of it that owns
every pending chord, so blur and pane teardown drop them the way the Enter path
already clears its state. The sender also bounds the wait — generous enough for
a conversion candidate window, and it discards rather than sends, because a
chord arriving mid-preedit is the corruption the wait exists to prevent.
The Enter path needs none of this: its 200 ms fallback always runs, so its
listeners cannot outlive it. Pinned so that stays true.
Fixes STA-4476
* refactor: split db.ts under 400 lines
* rm plan
* fix(orchestration-db): add safety guards to database operations
Add status guards to UPDATE statements to prevent late operations from
overwriting changes made by concurrent requests. Validate mutation results
to surface silent no-ops. Extract circuit-break threshold, add transaction
wrapping, and sanitize untrusted input. Bump schema version to v28.
* Add transactional safety to dispatch and message operations
Wrap dispatch failures and batched message updates with SAVEPOINTs to
ensure atomicity and idempotency:
- Dispatch failures now check status guards and roll back if the
related task update fails, preventing partial state corruption
- Message batches (across multiple 500-id chunks) roll back entirely
if any batch fails, avoiding partial mutations
- Add tests verifying idempotency and atomicity under failure conditions
* Handle concurrent writes and improve transactional safety
- Remote question answering: add classification check before and after UPDATE to safely detect concurrent modifications. Prevents false success when the UPDATE loses a race.
- Transaction rollback: wrap in try-catch to prevent errors from masking the original failure.
- Question thread reset: use status update instead of deletion to preserve message references.
* test: add answer replay and race condition edge case coverage
Add test cases for answer replay idempotency, conflict detection, and a race condition between concurrent answer updates in federation relay. Also verify local question state transitions during orchestration reset.
Jinjing
Jinwoo Hong
Brennan Benson
github-actions[bot]
NeilandBaeTab
SebastianandBrennan Benson
