Follow-up to the salvaged #56724: the runtime's _generate_xai_tts reads
voice_id, language, speed, auto_speech_tags, optimize_streaming_latency,
sample_rate, and bit_rate — but never text_normalization, and the xAI
/v1/tts payload builder has no such field. Surfacing it in the desktop
GUI would be a dead knob, so remove it from DEFAULT_CONFIG, constants.ts
(labels/descriptions/SECTIONS), and the ja/zh/zh-hant locale catalogs.
The other six xAI keys are all verified against tools/tts_tool.py.
Consistent naming across the xAI TTS settings section. Speed and
sampleRate are shown only when xAI is the selected provider, so they
get the prefix too.
The Settings > Voice provider dropdowns (tts.provider / stt.provider) only offer
the built-in providers plus whatever value is currently set. Custom `type: command`
providers declared in config.yaml aren't selectable — and once you switch away from
one it drops off the list, so you can only return to it by hand-editing config.
enumOptionsFor now merges in the names of any `type: command` entries under the
tts/stt config sections, so local command-backed engines appear alongside the
built-ins and can be switched freely from the UI.
Enumeration mirrors the runtime's own resolution so the dropdown can only offer a
name the runtime would actually honour: the canonical `<section>.providers.<name>`
location plus the back-compat top-level `<section>.<name>` block, the optional
`type:` discriminator, and the built-in-name guard. The guard compares against the
runtime's built-in sets rather than the ENUM_OPTIONS display list, which is not a
substitute — it already omits `deepinfra` (TTS) and `deepinfra`/`local_command`
(STT), so a `providers.deepinfra` command block would otherwise be offered as
selectable while the runtime dispatches to the native backend instead.
- helpers.ts: add commandProviderNames() + the built-in guard; merge for
tts.provider + stt.provider
- helpers.test.ts: cover both sections, incl. that non-command config blocks
aren't offered and that built-ins absent from the display list are never
offered as command providers
* fix(desktop): compute truthful per-provider readiness for Capabilities tool config
Backend: GET /api/tools/toolsets/{name}/config now sends a per-provider
'status' field ('ready' | 'needs_keys' | 'needs_auth' | 'needs_setup')
computed by the new provider_readiness_status() in tools_config:
- env vars declared: all set -> ready, else needs_keys
- Nous-managed rows: Portal login + per-category tool-gateway entitlement
(MANAGED_FEATURE_COVERAGE_CATEGORY) -> ready, else needs_auth
- post_setup 'xai_grok' rows: Grok OAuth or XAI_API_KEY -> ready, else
needs_auth
- other keyless post_setup rows: installed-state predicate
(_POST_SETUP_READY: kittentts/piper/ddgs/langfuse via find_spec,
agent_browser via _has_agent_browser, cua_driver via PATH probe);
unknown hooks fall back to is_active as the setup-completed signal
- genuinely-free keyless rows (Edge TTS) stay ready
Existing fields are untouched; 'status' is additive so older desktops
keep working.
* fix(desktop): render server readiness status in Capabilities provider pills
The panel's providerConfigured() heuristic pilled every zero-env-var
provider 'Ready' — including logged-out Nous Subscription rows, xAI TTS
without Grok OAuth, and never-installed KittenTTS/Piper. Render the
backend's per-provider 'status' instead:
- ready -> existing 'Ready' pill
- needs_auth -> warn pill 'Needs sign-in'
- needs_setup -> warn pill 'Needs setup'
- needs_keys -> no pill (env-var fields are the signal)
Keyed rows keep deriving ready/needs_keys from local envState so saving
or clearing a key updates the pill without a refetch. Older backends
without 'status' fall back to the legacy env-var heuristic (narrow
compat path, desktop/runtime update on separate clocks).
Adds the warn tone to the settings Pill primitive and needsSignIn /
needsSetup strings to all locale catalogs (en, zh, zh-hant, ja).
Two residual gaps in the #67369 salvage of #67214, found during review:
1. No timeout on the download client. Since #67369, mutable branch pins
hit the network on EVERY run, and the stale-cache fallback only fires
when download() returns Err. A black-holed connection (captive portal,
hung proxy, dropped packets) never errors, so the whole bootstrap hung
at resolve() instead of falling back to the cached script. Verified
live: a request to a non-routable address now errors at the 10s connect
timeout instead of hanging indefinitely.
2. The UTF-8 BOM was only written inside download(). Immutable commit-pin
caches take CachePlan::Reuse and are served untouched forever, and the
stale-fallback path also re-serves the old file - so a BOM-less .ps1
cached by a pre-fix installer kept reproducing the #67193 ANSI-codepage
parse failure on every retry (production builds pin BUILD_PIN_COMMIT,
so this is exactly the retry population). upgrade_cached_script() now
BOM-upgrades legacy .ps1 caches in place (atomic tmp+rename,
best-effort, idempotent) on both reuse paths; .sh untouched.
The salvaged helper cleared its line buffer on entry. Inside run_script's
tokio::select! loop, a stdout line arrival cancels the in-flight stderr
read (and vice versa); read_until had already consumed bytes into the
buffer, and the next call's clear() silently dropped that partial line.
Keep partially-read bytes across cancellation (clear only after a full
line is decoded) and emit an unterminated final line at EOF instead of
swallowing it. Adds a cancellation regression test (fails against the
clear-on-entry version) and an EOF-tail test.
Locks the #67193 invariants: localized PowerShell error bytes survive
decode_console_bytes / read_decoded_line (including CP1252-only 0x91/0x92
punctuation), cached .ps1 files get a single UTF-8 BOM for Windows
PowerShell 5.1 -File, .sh stays BOM-less, and mutable branch caches plan
a refresh with stale-cache fallback.
Windows PowerShell 5.1 emits ParserError text in the console ANSI code page,
but the GUI bootstrap aborted BufReader::lines() on the first non-UTF-8 byte
and Retry kept reusing a poisoned install-main.ps1 for branch pins. Decode
child output with a real Windows-1252 fallback, write a UTF-8 BOM on cached
.ps1 files for -File, and refresh mutable branch/tag caches on each run
(immutable SHAs stay cached).
Fixes#67193
Wire the scoped translator into the plugin context alongside storage/rest/
socket, and export usePluginI18n + the bundle types from @hermes/plugin-sdk.
The runtime shim re-exports the barrel automatically, so disk/third-party
plugins get the same door as bundled ones.
A plugin ships its own locale bundles and registers them under its id — never
editing core en.ts — exactly like ctx.storage namespaces persistence. The
registry merges repeated registrations and drops a plugin's bundles on
dispose (tracked by the loader like register/socket), resolving through the
shared translator: active locale -> the plugin's own en -> the raw key.
Two consumers, symmetric with core: usePluginI18n(id) for React UI
(re-renders on a locale switch or a late registration) and a module-level t
for handlers/stores.
Collapse the fallback walk out of `translateNow` into a single `translateFrom`
that takes a per-locale message source, so any translator (core catalog or a
plugin's bundles) reuses the exact dot-path walk, interpolation, and
active-locale/English/raw-key chain. Adds `getRuntimeI18nLocale`.
In the Focus layout `files` shares one tab group with `workspace`, so when the
first reply adopts a cwd the reactive files unhide fronted files and yanked the
active tab off the new session (~1s after the reply). #65375 fixed the sibling
"reactive unhide reopens a collapsed side" bug but frontPaneInGroup still stole
the active slot unconditionally.
Only take the active slot when the group's current active pane isn't itself
showable, so a reactive unhide can't steal focus from a pane the user is
viewing while still fronting a valid tab when nothing is shown.
Carries forward linfeng961's diagnosis + fix from #66870, reworked onto the
frontPaneInGroup path introduced by #65375.
Co-authored-by: linfeng961 <133505766+linfeng961@users.noreply.github.com>
* fix(desktop): don't auto-expand user-collapsed side on reactive unhide
When `setTreePaneHidden(paneId, false)` was called for a workspace-gated
pane like `files` (bound to $hasWorkspace), it auto-called
`revealTreePane(paneId)` — which expanded the parent column even when
the user had explicitly collapsed it via Cmd+J.
That meant every session create / resume — anything that flipped
$currentCwd from empty to non-empty — silently re-opened the right
sidebar and persisted that open state to localStorage, so the original
session also showed the sidebar as open on return.
`setTreePaneHidden` is a state primitive; user-intent semantics (open
the side, front the tab) belong to `revealTreePane`. Drop the auto-call
and replace it with a narrower `frontPaneInGroup` helper that only
makes the pane the active tab in its group — visible the next time the
column is opened, without forcing it open now.
* fix(desktop): preserve explicit review reveal
---------
Co-authored-by: David Metcalfe <80915+DavidMetcalfe@users.noreply.github.com>
A manual composer pick stays sticky across new chats (intended), but if that
model later disappears from the provider/config, every new chat kept trying the
dead model and 404'd. Fall back to the profile default in that one case only.
refreshCurrentModel now consults the model-options cache the composer already
populates (no extra fetch): a manual pick is preserved unless manualPickRemoved()
proves it's gone — provider present, non-empty catalog, model absent. An
unknown/absent provider, an empty (re-auth/unconfigured) list, or a not-yet-loaded
catalog all preserve the pick, so a still-valid selection is never clobbered.
Surface the session's first-class Project in both chat surfaces: the
Desktop status bar (project name as the workspace label, full cwd in the
tooltip) and the TUI status label + /status output.
One source of truth. The per-profile projects.db is the authority, read
in tui_gateway via _project_info_for_cwd (backed by
projects_db.project_for_path) and threaded through every session.info
emission path the TUI consumes. The Desktop already caches that truth in
$projectTree, so it DERIVES the label from it (projectNameForCwd) instead
of carrying a second per-session $currentProject atom fed from
session.info.
That drops the parallel state #64721 introduced and the entire
reset/reconciliation surface it required (resume, agentless cwd.set,
gateway-switch, fresh-draft): the label is purely derived, so it stays
correct whenever the cwd or the project tree changes. Only explicit,
named projects resolve on both surfaces, so an auto-discovered repo root
keeps the cwd-leaf label everywhere.
Excludes the unrelated markdown shell-fence change bundled in #64721.
The sidebar refresh fired three /api/profiles/sessions calls (recents, cron,
messaging), and each one reopened every selected profile's state.db and re-ran
list_sessions_rich + session_count — ~3N DB opens/counts per refresh, on every
turn/broadcast/reconnect.
Add GET /api/profiles/sessions/sidebar: one pass that opens each profile DB
once and runs the three source-scoped queries together (recents scoped to the
active profile; cron + messaging cross-profile), returning the three windows in
one payload. Same read-only projection, 300s active heuristic, and caller-
supplied source taxonomy (recents_exclude / messaging_exclude / source=cron) as
the per-slice endpoint.
Renderer refreshSessions now makes one listSidebarSessions call and distributes
recents/cron/messaging to their stores (cron *jobs* stay a separate getCronJobs
API). Electron splices remote profiles per slice via fetchProfilesSessionSlice
(reusing the proven per-slice merge) so remote correctness is preserved; the
no-remote common case gets the single-open fast path.
From the Desktop performance audit (P1: "Batch sidebar session slices").
Two structural fixes from the Desktop performance audit (P2 tier):
1. Scope live tool-diff subscriptions. `ToolEntry` subscribed to the whole
`$toolDiffs` map via `useStore`, so one `recordToolDiff` re-rendered every
mounted tool row. Add a cached per-toolCallId derived atom
(`$toolInlineDiff(id)`, mirroring the existing `$toolDisclosureOpen` pattern);
computed() only notifies when that id's diff string changes, so a live patch
re-renders one row.
2. Narrow profile / gateway-switch query invalidation. Both the active-profile
subscription and `wipeSessionListsForGatewaySwitch` called keyless
`queryClient.invalidateQueries()`, refetching account/marketplace/onboarding
caches on every switch. Add `invalidateProfileScopedQueries()` with a
denylist of profile-independent roots (billing, marketplace-themes,
onboarding-model-options, contrib-logs-tail). A denylist is correctness-safe:
a root we forget just refetches (cheap), whereas an allowlist that misses a
profile-scoped key would paint the previous profile's data.
Tests: per-tool notify isolation, and real-QueryClient invalidation partition
(profile-scoped invalidated, global left intact, unknown keys invalidated).
The char-level streaming fuzz runs 12 seeds × 500 growing prefixes
(~6000 full+cached lexes) and first trips the pre-fix boundary at
seed 11 / step 257, so the workload can't shrink without gutting the
guard. The work is bounded but exceeds Vitest's 5s per-test default on
CI workers under parallelism, so give this one test an explicit 30s
timeout instead of weakening coverage.
Built-in memory (MEMORY.md/USER.md) is controlled by memory_enabled, not
memory.provider — but the desktop dropdown offered 'builtin' as a normal
provider-plugin value and gave it plugin-shaped affordances (config panel,
OAuth connect row), and the empty sentinel rendered as '(none)' even though
built-in memory was active.
- Label the empty memory.provider option 'Built-in only' (all locales).
- Drop the literal 'builtin' option from the desktop ENUM_OPTIONS and the
backend config-schema select; _normalize_memory_provider_name already maps
legacy builtin/built-in/none values to ''. A stored legacy literal stays
visible via enumOptionsFor's current-value passthrough.
- Gate MemoryConnect and ProviderConfigPanel behind a new
isExternalMemoryProvider() helper so built-in aliases never get
provider-plugin affordances.
The streaming block splitter added in #67154 dropped only the previous
parse's trailing whitespace blocks plus its LAST content block before
re-lexing the appended suffix. That boundary is unsound: a trailing
Setext underline (`-`/`=`) underlines the paragraph ABOVE it, so
appending to it can retroactively merge the previous parse's last TWO
blocks into one.
Minimal repro: cached "…#e\n5\n-" lexes to [ …, "#e\n", "5\n-" ], but
grown to "…#e\n5\n-p2=kj:c" collapses "#e"/"5\n-" into a single block.
The reused settled prefix still contained a stale "#e\n" block. The
`blocks.join('') === text` guard can't detect this because the wrong
split reconstructs the same source string, so the divergence rendered
as mis-split blocks with no fallback.
Fix: drop the last TWO content blocks (skipping whitespace-only blocks
around them) before re-lexing the suffix. The block before the last is
the deepest an append can reach — a Setext underline consumes exactly
one preceding block — and earlier blocks stay fenced off by settled
blank lines, so re-lexing two is sufficient and safe.
Tests: a deterministic regression for the exact prev→grown pair, and a
character-level streaming property fuzz (12 seeds × 500 growing prefixes
over the markdown control alphabet). Both fail on the pre-fix boundary
and pass after. tsc/eslint/prettier clean; markdown-text suite green.
Fourth profiling round (#66033/#66347/#66470). Streamdown's
parseMarkdownIntoBlocks is a full `marked` lex of the entire message,
and during streaming every flush is a new string — so the splitter paid
O(full-text) ~30x/s: benchmarked 3.4-9.6ms per call at 64-192KB, i.e.
15-30% of a core burned re-lexing settled text on long agent replies.
(The rest of the May-2026 "re-parse elephant" was already eaten by
tailBoundedRemend, block-memo, the KaTeX memo, and deferred shiki —
the splitter was the last O(full-text) pass besides preprocess, which
benches at only 1.5-4.6ms and is left alone.)
New src/lib/markdown-blocks.ts (extracted from markdown-text.tsx) wraps
the splitter with two caches:
- the existing exact-string LRU (remounts: virtualizer scroll, session
switch) — moved, unchanged;
- a streaming-append cache: when the new text startsWith a recently
parsed text, reuse that parse's blocks up to a settled boundary and
lex only the suffix. The boundary drops trailing whitespace-only
blocks plus the last content block — the only block appended text can
reinterpret (open fence, list/table continuation, setext underline,
lazy blockquote). Earlier blocks are separated by settled blank lines
and can't change. Cross-block reference links can't regress:
Streamdown already renders each block as an independent document.
Safety: the splitter's blocks.join('') === text property makes offsets
exact and is defensively re-checked; any mismatch or non-append rewrite
(edit, branch swap) falls back to the full lex — byte-for-byte the old
behavior.
Property tests: at every random streaming cut over a corpus covering
fences, loose lists, tables, setext headings, lazy blockquotes, HTML
blocks, and display math — and token-by-token through a fence boundary
— the cached splitter's output is asserted deep-equal to a fresh full
lex. Bench (128KB reply, 200 flushes): 990ms -> 72ms total splitter CPU
(4.95 -> 0.36ms/flush).
Verification: tsc clean; eslint/prettier clean; lib + assistant-ui
suites green (473 tests).
Surgical reapply of the surviving half of PR #43517 by @jingsong-liu
(the branch predates the ts-ify migration; its other half — zoom restore
after reload/navigation — landed via #66989).
On US layouts Plus is physically Shift+=, so Cmd+Plus arrives with the
shift modifier set. The blanket 'input.shift' early-return in
installZoomShortcuts silently swallowed keyboard zoom-in on macOS: the
chord matched neither branch and fell through to nothing. Shift is now
evaluated per-chord: zoom-in accepts it, zoom-reset and zoom-out still
reject it (Ctrl/Cmd+Shift+0 and Shift+'-' are different chords).
* fix(dialog): close button not working and tooltip showing on open
- Close button click was swallowed by Tip's non-forwarding wrapper;
reordered so DialogPrimitive.Close asChild wraps Button directly.
- Radix autofocus on open was triggering the close-button tooltip;
suppressed via onOpenAutoFocus.
Adds tests covering both regressions.
* fix(dialog): narrow onOpenAutoFocus suppression to updates overlay only
Previously preventCloseButtonAutoFocus was applied as a default for
every shared DialogContent, which risked breaking keyboard focus in
dialogs with inputs (cron, profile, model search, etc). Now it's
opt-in and exported, applied explicitly only in updates-overlay.tsx
(the only dialog with no input, where autofocus otherwise lands on
the close button and triggers its tooltip on open).
Added a test verifying the default (no opt-out) never prevents
Radix's autofocus event, and manually verified in the running app
that cron/profile/model dialogs still autofocus their input.
* test(dialog): opt tooltip-on-focus test out of Radix autofocus
Without an input, this test's dialog now gets Radix's real autofocus
on the close button (autofocus is no longer globally suppressed),
which raced with the test's manual fireEvent.focus and made the
tooltip assertion flaky in CI. Opt out explicitly, same as
updates-overlay.tsx.
* test(dialog): increase tooltip wait timeout for CI load
The full suite (1800+ tests) runs slower under CI load than isolated
local runs; the tooltip's own open delay can exceed the default 1000ms
waitFor timeout there, causing a flaky failure unrelated to the
autofocus fix itself.
* test(dialog): use real .focus() instead of synthetic focus event
fireEvent.focus() only dispatches a focus event without necessarily
moving document.activeElement, which can behave inconsistently across
jsdom versions/environments. Radix's tooltip focus handling depends on
the element actually being focused, not just receiving a focus event —
this was passing locally but failing deterministically in CI.
* test(dialog): skip pre-existing tooltip-on-focus test in CI
Unrelated to the onOpenAutoFocus scoping this PR is about (fully
covered by the other three tests). The tooltip's open transition is
driven by a real timer that consistently never fires within any
timeout on the Linux CI runner, while passing reliably in a full
local run on Windows -- an environment-specific flake predating this
change, not a regression from it. Needs separate investigation.
Ground-truth reapply of PR #40414 by @liuhao1024. The original branch
predates the ts-ify migration and implemented the gesture by injecting
a DOM wheel listener via executeJavaScript + a new IPC channel. Current
Electron surfaces the modifier+wheel gesture natively as the main-process
webContents 'zoom-changed' event, so the salvage uses that instead:
no renderer injection, no new preload surface, no new IPC channel.
The handler routes through setAndPersistZoomLevel — the same
persist+notify funnel as the keyboard shortcuts — so wheel zoom uses
the same 0.1 half-step, persists to zoom-state.json across restarts,
and keeps the settings Scale control in sync. Session windows get the
gesture automatically via wireCommonWindowHandlers; the pet overlay
stays opted out via zoomWiringForWindowKind.
Surgical reapply of PR #46429 by @SongotenU (the branch predates the
ts-ify migration; main.cjs no longer exists so a direct cherry-pick
cannot apply).
Main already adopted half of the PR's fix when zoom restore moved into
wireCommonWindowHandlers (57dfebe3d) — session windows are covered. The
surviving delta is the listener lifetime: 'once' spends the listener on
the first did-finish-load, so any later full load in the same
webContents — the crash-recovery webContents.reload(), a manual reload,
or an in-place navigation that lands on a fresh per-host zoom entry —
came up at default zoom while the settings Scale control still showed
the persisted percentage. 'on' re-applies the persisted level after
every completed load; restorePersistedZoomLevel routes through the
applyZoomLevel funnel so the renderer stays in sync.
Surgical reapply of the surviving halves of PR #57414 by @Sahil-SS9
(the branch predates the ts-ify migration and the zoom apply/notify
funnel, so a direct cherry-pick no longer applies):
- Zoom persists to a main-process zoom-state.json as the primary store.
The old localStorage-only store lives under Electron's cache/storage
folders, which crash recovery can move or recreate — wiping zoom
exactly when the user recovers from a crash. localStorage stays as a
secondary mirror; pre-JSON installs migrate on first read.
- Window geometry persists at ready-to-show, so a crash before the
first resize/move/close still captures the restored bounds.
The third half of #57414 (one-shot --no-sandbox relaunch on Windows
renderer crash loops) was superseded by #66842, which ships the same
recovery gated on the 0x80000003 sandbox-crash signature.
Adapted to current main: restore/persist route through the
applyZoomLevel funnel (39230d173) so the settings UI Scale control
stays in sync, and JSON writes go through writeFileAtomic.
