Mobile direct-chat dropdowns now identify sessions by conversation title instead of model-name text.
- Render the mobile session trigger with the conversation title or Untitled while preserving the provider logo.
- Remove mobile trigger model-tag styling and assert the model badge stays out of the compact header.
- Document the mobile Chat dropdown behavior and add a patch changeset for the published CLI package.
Files changed:
.changeset/fn-7462-mobile-chat-dropdown-title.md | 7 ++++
docs/dashboard-guide.md | 2 +-
packages/dashboard/app/components/ChatView.css | 8 -----
packages/dashboard/app/components/ChatView.tsx | 8 +++--
.../__tests__/ChatView.core-contracts.test.tsx | 25 +++++++++++---
.../components/__tests__/ChatView.mobile.test.tsx | 39 +++++++++++++++++++++-
6 files changed, 72 insertions(+), 17 deletions(-)
Fusion-Task-Id: FN-7462
Fusion-Task-Lineage: 6a6e2ac3-ecca-4076-81c5-b4e4a65eb286
Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
## Windows: local runtime hung at "Starting local Fusion runtime…"
### Root cause
Desktop startup had two independent persisted sources of truth that
could disagree:
- `desktop-launch-mode.json` — decides whether **main** *starts* the
embedded local runtime
- `shell-connections.json` (`desktopMode`) — decides whether the
renderer **launch gate** *waits* for it
`shell:setDesktopMode` persists shell settings **before** the fallible
`startLocalRuntimeOnce()` / `saveDesktopLaunchMode()`. So a first
"local" selection whose runtime start threw or was interrupted left
`shell=local` / `launch-mode=choose` **permanently**. Every later launch
then sat at "Starting local Fusion runtime…" polling a runtime nobody
started → 30s timeout.
### Fix (defense in depth) — `78f0bc31`
- `initializeApp` reconciles: a completed shell `local` selection is
authoritative → heals the launch-mode file and starts the runtime.
- `onDesktopModeChange` / `onDesktopLaunchModeChange` persist
launch-mode **before** the fallible start so it can't re-desync.
- `DesktopLaunchGate` no longer assumes main started the runtime — if
it's not running/starting it actively `setDesktopMode("local")` before
polling.
- Env-gated startup trace (`FUSION_STARTUP_TRACE`) so packaged builds
(which log nothing) are diagnosable.
- Regression tests: split-brain → runtime starts + file heals;
agreement-on-choose → no start.
**Verified end-to-end under real Electron 35 / Node 22.16**: from the
exact split-brain state the runtime now reaches `RUNNING` and the
launch-mode file heals.
### Also: Windows root-build breakages — `bd24bd4c8`
- `scripts/build-workspace.mjs` "run as main" guard compared
`import.meta.url` to `` `file://${process.argv[1]}` ``, which never
matches on Windows → root `pnpm build` silently no-opped (exit 0, no
dist). Now uses `pathToFileURL(process.argv[1]).href`.
- `spawn('pnpm', …)` without `shell:true` (ENOENT on Windows) in
`build-workspace.mjs` and `packages/cli/tsup.config.ts` → pass `shell`
on win32.
### Notes
- `@fusion/desktop` and `@fusion/dashboard` are private → no changeset.
- Build the Windows installer via the `desktop-windows` workflow
(`electron-builder --projectDir deploy`); local `pnpm deploy` staging
hits an unrelated directory-rename race on managed-workspace
filesystems.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added optional desktop runtime startup tracing (enabled via
environment variable).
* **Bug Fixes**
* Improved local desktop handoff to prevent reload loops and navigate
directly to the embedded local runtime.
* Added “split-brain” healing between persisted launch mode and shell
settings.
* Prevented auto-registration of runtime root/CWD during
desktop/dashboard startup.
* Improved Windows compatibility for CLI/workspace command spawning and
npm install process handling.
* **Tests**
* Expanded local/Electron integration, navigation, and onboarding
regression coverage; improved async flushing for more reliable
initialization.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
- Right dock now defaults to HIDDEN when the operator has no stored preference (readStoredRightDockOpen),
so first-run/onboarding lands on an uncluttered board; users opt in via the Header toggle (persists
"true"). Combined with the existing taskView="board" default and viewMode->"project" transition, first
run lands on the board. Updated the design comments and controller Harness tests (seed the open flag)
and added a focused default-closed assertion.
- useDeepLink deferred the "Project 'X' not found" toast behind a 3s grace window. A project selected
during onboarding is deep-linked via ?project=<id> before the projects list revalidates to include it,
so the eager toast fired even though the project loads a beat later. The deferred toast is cancelled as
soon as the project appears in the list; only a genuinely-absent project past the window still errors.
Added symptom-verification coverage (project appears within window -> no toast) and updated the
StrictMode/unknown-project/App-level tests to advance fake timers.
- Removed the stale ModelOnboardingModal test asserting the research-runs note that was intentionally
removed from onboarding earlier.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Stale SWR hydration entries (per-chat-session/per-room message caches up to
500KB each) were never garbage-collected — readCache returned null for stale
entries but left the bytes on disk, and nothing swept abandoned caches. This
caused localStorage quota exhaustion for users with many projects and chat
sessions.
Three fixes:
- readCache now lazily deletes stale entries (behavior-preserving; every
reader already treats stale as a miss and re-fetches)
- Boot sweep pruneStaleCacheEntries() in DashboardLoader removes any
kb-dashboard-* entry older than 24h before hydration hooks read caches
- Settings > General "Browser Data" panel with a Clear local data button
that wipes all Fusion-owned browser data while preserving the auth token
Also completes the vitest localStorage mock (was missing length/key).
Two false-positive first-run banners:
1. "Select Default Model" recommendation appeared even after choosing a model in onboarding.
The picked model lived only in local state until completeOnboarding ran on the final step, so
selecting a model then exiting/skipping before the last step lost the choice — and
defaultProvider/defaultModelId stayed unset, tripping the recommendation. Now the pick is persisted
immediately in handleModelSelect, and completeOnboarding falls back to the first available model
when the operator connected a provider but never opened the dropdown. Either path leaves a durable
global default so the recommendation no longer misfires.
2. "Install the Fusion CLI" banner showed immediately on first run. Added a 3-day grace period keyed
off the first time the banner becomes eligible; Settings -> General -> CLI Binary still installs on
demand meanwhile, so this only defers the passive nudge.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
useDashboardHealth fetched /api/health once on mount and never again. Right after a project is
created the engine is still starting, so that single fetch reports engine.available=false and the
"AI engine is not running" banner shows — and because health was never refreshed, the banner stayed
up even after the engine came online (the user reported the banner while the engine was in fact
running). Poll every 15s and preserve the last value on transient errors so the banner clears on its
own once the engine reports available.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The project name auto-derives from the chosen directory, so present the folder/directory picker
before the Project Name field — picking the folder first pre-fills a sensible name instead of
asking for a name before there is a folder to base it on.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
On the GitHub onboarding step, when GitHub is authenticated via the gh CLI (no OAuth provider),
the "Continue with gh CLI auth" button called setStep("project-setup") directly, skipping the
completion bookkeeping — so "github" was never added to completedSteps and step 2 never checked
off in the progress indicator. Advance via handleNext when ready via gh CLI (marks the step
completed) and via handleSkip when GitHub isn't connected (marks it skipped).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Remove the "Research runs require provider credentials and an enabled Research View…" helper note
from the AI-setup step.
- Show the "Connect remote Fusion server" card only when not already connected to a remote server
(no active remote profile) — on any host including web — and never in LOCAL desktop mode, where the
local runtime is already the backend and prompting for a remote URL just confused first-run setup.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
createServer's modelRegistry is optional and, when absent, the /api/models endpoint returns an
empty list — so after connecting a provider (e.g. Anthropic) the onboarding model picker showed
"no models". The desktop wired authStorage but no ModelRegistry.
Add a shared createFusionModelRegistry(authStorage) factory to @fusion/engine (which already depends
on @earendil-works/pi-coding-agent) so non-CLI hosts don't need that dep directly, and pass its
result as modelRegistry from both desktop server paths. Verified against a clean embedded server:
/api/models now returns 24 Claude models instead of an empty list.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
local-server now imports createFusionAuthStorage from @fusion/engine; add it to the test's engine
mock so the startup path resolves.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The desktop embedded server called createServer WITHOUT an authStorage, so GET /api/auth/status
returned 500 "Authentication is not configured". The dashboard's first-run onboarding hook
(useAuthOnboarding -> fetchAuthStatus) catches that failure silently and never opens the model
onboarding wizard — so the desktop skipped straight to project creation with no AI/GitHub setup,
regardless of onboarding-completion flags (which is why clearing them did nothing). Providers also
couldn't be authenticated at all.
Wire createFusionAuthStorage() (the same storage the CLI dashboard/serve commands use) into both the
primary (local-runtime) and legacy (local-server) desktop server paths. Verified against a clean
embedded server: /api/auth/status now returns 200 with the provider list instead of 500. (Full
API-key provider wrapping stays CLI-only for now; OAuth + CLI providers are available on desktop.)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
POST /api/projects registered a project but only started its engine lazily on the first scoped
store access, so a freshly-created project — especially the operator's FIRST project on the
desktop, where no other engine is running — left engineManager with no running engine. The
dashboard's project view then showed "AI engine is not running" (EngineUnavailableBanner keys off
/api/health engine.available). Proactively warm the engine via getOrCreateProjectStore (fires the
onProjectFirstAccessed hook -> engineManager.onProjectAccessed -> ensureEngine) right after the
project is activated, fire-and-forget so it never blocks/fails the registration response.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- DesktopLaunchGate: the chooser onPick("local") path still called the removed
applyServerBaseUrl helper (broke Typecheck and the desktop local chooser flow) —
call navigateToLocalRuntimeOrigin. Also re-read shell.getState() immediately before the
self-healing start check so a stale mount snapshot doesn't fire a redundant
setDesktopMode("local") on normal boots (Greptile).
- register-fn-binary-routes: on Windows the npm install runs under a shell, so a timeout's
child.kill only stopped cmd.exe and left npm.cmd/node running — kill the whole process tree
via taskkill /T on win32 (CodeRabbit).
- local-server.test: align with the new resolver contract — assert the runtime never
auto-registers the root project and starts engine-less when no projects exist (CodeRabbit).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
useAuthOnboarding gated its first-run check on `providers.length > 0`, so a brand-new install
(notably the desktop app on first launch, which can report zero configured providers) skipped
onboarding entirely and landed the operator on an empty dashboard with no AI/GitHub setup.
Evaluate first-run onboarding from completion state regardless of the provider list, so brand-new
users are guided through the model-onboarding wizard (AI -> GitHub -> Project) before project
creation. Existing branches (authenticated provider, completed onboarding, local completion,
setup-wizard deferral, one-shot guard) are unchanged. Adds an empty-provider-list regression test.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The desktop embedded runtime auto-registered its runtime root (the user's HOME directory) as a
project on first launch, and bare `fusion` / `fn` / `fn dashboard` / `fusion dashboard`
auto-registered the CWD as a project. Both silently created a "cwd-mode" project the operator
never chose and dropped them onto a board for it.
- Desktop: replace ensureDesktopRuntimeProject (which registered home) with
resolveDesktopRuntimePrimaryProject, which only PICKS an already-registered project as the
primary engine target and registers nothing. With no projects the server starts engine-less
(createServer's engine is optional) and the dashboard shows its onboarding empty state.
Applied to both the primary (local-runtime) and legacy (local-server) desktop server paths.
- CLI dashboard command: ensureCwdProjectRegistered now runs with autoRegister:false, so it uses
the CWD project only if already registered, else starts with none and the dashboard onboards.
(serve/daemon keep their existing --no-auto-register flag; the CLI `desktop` launcher unchanged.)
Verified: with zero projects the embedded server starts, /api/health -> 200, /api/projects -> [],
/ serves the client. Unit test asserts resolveDesktopRuntimePrimaryProject registers nothing.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The CLI-binary panel's "Install with npm" button (POST /system/fn-binary/install) ran
`spawn("npm", ["install","-g","runfusion.ai"], { shell: false })`. On Windows npm resolves to
npm.cmd, which Node refuses to spawn without a shell (spawn npm ENOENT / EINVAL, CVE-2024-27980),
so the button failed with "spawn npm ENOENT". Use shell on win32; the command/args are fixed
constants with no caller input, so shell quoting is safe. (The npx spawns in cli skills/extension
already set shell:true.)
Verified on Windows: spawn("npm",["--version"],{shell:false}) -> ENOENT; {shell:true} -> ok.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
After the runtime starts, the packaged renderer was left on its file:// page and only had
?serverBaseUrl=… appended. But the dashboard client issues RELATIVE /api requests, so on a
file:// origin they resolve to file:///api/… and fail ("Can't reach the Fusion backend /
Failed to fetch"); the embedded server also sends no CORS header, so a cross-origin fetch
would be blocked as well. (The server itself is fine — verified it serves both /api/health
and the client HTML at /.)
Fix: once the runtime is running, navigate the window to the runtime's OWN origin
(http://127.0.0.1:<port>/), which the embedded server serves — making /api same-origin.
This mirrors how remote mode already navigates to its server URL. The gate now treats "page
served over http(s)" as the ready signal (protocol check) instead of a serverBaseUrl URL
param; that also supersedes the previous cached-context handoff check (04fd91f6) and keeps
the reload loop closed, since bootstrapShellHostContext() strips shell query params at load.
Regression tests: navigates to the runtime origin exactly once from file://; renders the app
without navigating when already served over http; starts the runtime first when it isn't
running, then navigates.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
After the runtime starts, DesktopLaunchGate calls applyServerBaseUrl() which reloads the
page with ?serverBaseUrl=… so the shell-host bootstrap can route API calls to the embedded
server. But main.tsx runs bootstrapShellHostContext() at module load — BEFORE the gate's
effect — and it strips every shell query param from the URL via history.replaceState. The
gate then checked window.location.search for serverBaseUrl (after an await), always missed
it, and re-ran the handoff → window.location.replace → reload → strip → an infinite reload
loop that renders as rapid "Starting local Fusion runtime…" flashing that never connects.
This was latent until the split-brain fix (78f0bc31) let the runtime actually start and
reach the handoff.
Fix: detect the completed handoff from the CACHED shell-host context
(getShellHostContext().serverUrl), which the bootstrap preserves, instead of the stripped
URL (URL param kept only as a fallback).
Adds a DesktopLaunchGate regression test: with serverUrl present in the cached context but
stripped from the URL, the gate renders children and does NOT reload; on first load it
performs the handoff exactly once. Verified the test fails against the pre-fix gate.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Keep the mobile direct-chat header on a single left-aligned row without losing accessible context.
- Hide the direct-chat ViewHeader title shell from layout while preserving the accessible Chat heading.
- Keep the back button first and the active session switcher beside it on a non-wrapping mobile row.
- Extend mobile chat coverage for long duplicate session titles, Bot fallback labels, and the CSS layout contract.
- Document the updated mobile Chat header behavior and add a patch changeset.
Files changed:
.changeset/fn-7455-mobile-chat-header-layout.md | 7 ++
docs/dashboard-guide.md | 2 +-
packages/dashboard/app/components/ChatView.css | 17 +++--
packages/dashboard/app/components/ChatView.tsx | 4 +-
.../components/__tests__/ChatView.mobile.test.tsx | 80 ++++++++++++++++++++--
5 files changed, 98 insertions(+), 12 deletions(-)
Fusion-Task-Id: FN-7455
Fusion-Task-Lineage: fe14b542-ff6a-437b-ad89-8011c2b3c299
Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
Two Windows-only breakages in the build path:
- scripts/build-workspace.mjs: the "run as main" guard compared import.meta.url
to `file://${process.argv[1]}`, which never matches on Windows (import.meta.url
is file:///C:/… with forward slashes and a triple slash; argv[1] is C:\… with
backslashes and no scheme). So `pnpm build` at the repo root silently no-opped
(exit 0, no output, no dist) and packaging shipped empty/stale dist. Compare
against pathToFileURL(process.argv[1]).href instead.
- scripts/build-workspace.mjs runPlannedBuilds and packages/cli/tsup.config.ts
runWorkspaceCommand spawned `pnpm` without shell:true; on Windows pnpm is a
.cmd shim Node refuses to spawn without a shell (ENOENT/EINVAL, CVE-2024-27980),
failing with `spawn pnpm ENOENT`. Pass shell on win32 (args are fixed repo build
invocations with no shell metacharacters).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Desktop startup used two independent persisted sources of truth that could
disagree: desktop-launch-mode.json decided whether main STARTS the embedded
local runtime, while shell-connections.json (desktopMode) decided whether the
renderer launch gate WAITS for it. shell:setDesktopMode persists shell settings
before the fallible startLocalRuntimeOnce()/saveDesktopLaunchMode(), so a first
"local" selection whose runtime start failed or was interrupted left
shell=local / launch-mode=choose permanently. Every subsequent launch then sat
at "Starting local Fusion runtime…" polling a runtime nobody started, timing out
after 30s.
Fix (defense in depth):
- initializeApp reconciles: a completed shell "local" selection is authoritative;
it heals the launch-mode file and starts the runtime.
- onDesktopModeChange/onDesktopLaunchModeChange persist launch-mode BEFORE the
fallible start so an interrupted start cannot re-create the desync.
- DesktopLaunchGate no longer assumes main started the runtime; if it is not
running/starting it actively (re)starts via setDesktopMode("local") before polling.
- Add env-gated startup trace (FUSION_STARTUP_TRACE) so packaged builds, which
otherwise log nothing, can diagnose this class of stall.
Regression tests assert the invariant (split-brain -> runtime starts + file heals;
agreement-on-choose -> no start). flushPromises now drains via a macrotask so
run()-based tests observe a fully-initialized app regardless of async chain length.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Workflow settings now keep newer pending edits when earlier save requests finish.\n\n- Snapshot pending workflow values before saving so the request cannot mutate under the save.\n- Clear only keys whose pending value still matches the completed request in Workflow Settings and Project Models.\n- Cover same-key, clear-to-default, and model-lane edits made while saves are in flight.\n- Add a patch changeset for the published Fusion package.\n\nFiles changed:\n .changeset/fn-7451-workflow-settings-save-race.md | 7 ++\n .../app/__tests__/settings-sections.test.tsx | 109 ++++++++++++++++++-\n .../app/components/WorkflowSettingsPanel.tsx | 21 +++-\n .../__tests__/WorkflowSettingsPanel.test.tsx | 121 ++++++++++++++++++++-\n .../settings/sections/ProjectModelsSection.tsx | 25 ++++-\n 5 files changed, 272 insertions(+), 11 deletions(-)
Fusion-Task-Id: FN-7451
Fusion-Task-Lineage: 82f5e1cf-fabb-4fc6-936c-f42dcd9337ac
Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
Collapse the mobile direct chat header into the shared top row.
- Move the mobile direct-thread back button and session switcher into ViewHeader actions.
- Hide the redundant mobile thread header while preserving desktop thread identity and context details.
- Update mobile chat styling, docs, changeset, and header contract tests for the single-row layout.
Files changed:
.changeset/fn-7450-mobile-chat-header.md | 7 +
docs/dashboard-guide.md | 3 +-
packages/dashboard/app/components/ChatView.css | 53 +++++-
packages/dashboard/app/components/ChatView.tsx | 197 +++++++++++----------
.../__tests__/ChatView.core-contracts.test.tsx | 48 ++---
.../components/__tests__/ChatView.mobile.test.tsx | 76 ++++++--
6 files changed, 256 insertions(+), 128 deletions(-)
Fusion-Task-Id: FN-7450
Fusion-Task-Lineage: c266a9b8-7fb1-410e-9c35-adad4c6a2d47
Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
Command Center token analytics now attributes Last 30 days model usage from durable per-model timestamps.
- Filter per-model token buckets by their own last-used timestamps while preserving legacy task-level fallback rows.
- Count unique tasks across totals, groups, and time series to avoid double-counting multi-model usage.
- Cover model/provider groups, API routing, and TokensArea rendering for Last 30 days multi-model data.
- Add a patch changeset for the published CLI package.
Files changed:
.changeset/fn-7448-token-usage-last-30-days.md | 7 ++
.../core/src/__tests__/token-analytics.test.ts | 128 +++++++++++++++++++--
packages/core/src/token-analytics.ts | 92 ++++++++++-----
.../areas/__tests__/TokensArea.test.tsx | 50 ++++++++
.../register-command-center-routes.test.ts | 86 ++++++++++++++
5 files changed, 327 insertions(+), 36 deletions(-)
Fusion-Task-Id: FN-7448
Fusion-Task-Lineage: 5d5c976b-5623-4d7a-a728-5a3959deac1d
Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
Return successful GitHub issue import and close flows to the issue list.
- Clear the selected GitHub issue and switch mobile preview back to the list after successful import or close actions.
- Preserve the selected preview on failures so users can retry with the existing error affordance.
- Add regression coverage for desktop and mobile import/close success and failure navigation states.
- Document the post-import list reset behavior and add a patch changeset.
Files changed:
.changeset/fn-7442-github-import-return-list.md | 7 +
docs/dashboard-guide.md | 2 +-
.../dashboard/app/components/GitHubImportModal.tsx | 20 +-
.../__tests__/GitHubImportModal.test.tsx | 210 +++++++++++++++++++--
4 files changed, 218 insertions(+), 21 deletions(-)
Fusion-Task-Id: FN-7442
Fusion-Task-Lineage: e334a7c1-68de-48f7-be31-b036ba741685
Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
Keep Anthropic authentication options grouped at the top of Settings while preserving auth-state sections.
- Prioritize Claude CLI, Anthropic Subscription, and Anthropic API Key before other providers in the shared card order.
- Render supported CLI and non-CLI auth cards from one sorted list so other CLI providers cannot split Anthropic entries.
- Cover the mixed CLI plus Anthropic subscription/API-key ordering case and add a patch changeset.
Files changed:
.changeset/fn-7436-auth-anthropic-order.md | 7 ++
.../__tests__/AuthenticationSection.test.tsx | 103 ++++++++++++++++++++-
.../settings/sections/AuthenticationSection.tsx | 91 ++++++++++--------
3 files changed, 160 insertions(+), 41 deletions(-)
Fusion-Task-Id: FN-7436
Fusion-Task-Lineage: 653a0126-ea2b-43a6-a829-dc72dc47bfde
Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
