Operator could not log in to Anthropic or Codex on a fresh container: every
attempt ended "Login did not complete. Please try again.", while the same
providers worked flawlessly on their long-lived native install.
FusionAuthStorage.modify() is the seam pi persists a COMPLETED LOGIN through
(Models.login -> credentials.modify(provider.id, ...) in pi-ai models.js:198).
It resolved its write target with `creating: false` and returned before invoking
the callback whenever the provider had no credential row yet:
const target = this.resolveWriteTarget(provider, current, false);
if (!target || !this.credential(target, current)) return { changed: false };
So a first login completed its browser flow, exchanged the code, took and
released the lock file, wrote NOTHING, and resolved as success — leaving the
dashboard poll to see authenticated:false and report the generic failure.
It reproduces only on a store with no existing row, which is why it looked
environment-specific: an install that has logged in before takes the same path
as a refresh over an existing row and is fine, while every new container, new
machine, or wiped ~/.fusion can never complete a first login for ANY provider.
Evidence from the operator's container: flow ended with err=None (pi resolved,
no error), nothing logged, auth.json still {}, the agent directory's mtime
bumped when the lock was taken and released while auth.json itself never
changed, and an API-key write — which goes through set(), not modify() — landed
immediately.
modify() now creates when absent and updates when present; a callback returning
undefined still writes nothing, so pi's refresh-bails-out behaviour is unchanged.
auth-storage-instances.test.ts asserted the old behaviour, grouping modify() with
remove/logout/removeInstance as "non-creating". The removal guarantees are kept;
the modify() assertion is inverted, because it encoded the defect.
Also surfaces the server's own loginError through a new describeLoginFailure()
helper instead of the generic sentence, so an OAuth state mismatch reads as the
stale-tab instruction it is. Writing its test caught a bad regex of mine:
`code.*expired` matched "OpenAI Codex ... token_expired", a different failure.
Verified: the new first-login test fails against the old `creating: false` and
passes with the fix; 86 engine auth tests, 238 dashboard auth/dialog tests, and
pnpm test:gate all pass.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Operator report: during a container login there was nowhere obvious to paste the
redirect URL and no sign of what the app was waiting on. The flow was split
across a pre-flight confirm that warned about paste-back and vanished, a card
that shrank to a disabled "Waiting for login…" chip, and the paste field
rendered inline in that card below the fold of a scrolling modal.
ProviderLoginDialog now opens with the flow and stays until it ends: a two-step
progress list, a button to re-open a lost sign-in tab, the paste field, and the
terminal outcome inline instead of a toast that disappears while the operator is
in another browser tab.
Three defects found and fixed while verifying it in a real container:
- It sank behind the onboarding modal and clicks landed on the modal instead.
createPortal relocates the DOM node but NOT the React tree, so pointer events
bubbled to the host FloatingWindow, which raises itself to a fresh
nextFloatingZ() on every pointerdown — each click in the dialog lifted the
window above it. Fixed by rendering the dialog as a sibling of the window,
claiming z once on open (it was calling nextFloatingZ() inline on every render
of a modal that re-renders on a 2s poll), and stopping propagation on the
overlay. Ratcheted for every portaled .modal-overlay.
- Spacing did not match any other dialog: it hand-rolled header/action padding
instead of using .modal-header/.modal-actions, and padded each child
separately. Every row now shares var(--modal-padding) — verified at a uniform
17px inset across header, steps, paste prompt, field, Submit, and actions.
- The paste field was invisible (.form-input fills with var(--surface), and so
does .modal — measured #0c0c0e on #0c0c0e), Submit was a 25px row-density
btn-sm, and both could scroll out of reach. The field now sinks to var(--bg)
with var(--border-strong), Submit takes standard control padding, and the
paste region is pinned outside the scroll area.
Dialog anatomy rules (spacing primitives, portal/stacking) documented in
docs/dashboard-guide.md.
Verified: 441 dashboard tests including 4 new dialog tests, eslint, dashboard
typecheck, and the rendered dialog measured in a container build.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Operator report: the first-run "Set Up AI" modal had extra space along its right
edge, and it asked a browser visitor to connect a remote server and mentioned a
native shell they do not have.
Three defects, verified in a real container build at desktop and mobile widths:
- FN-8015 reserved `margin-inline-end: var(--space-lg)` on the shared
`.floating-window__body` so a hosted scrollbar cleared the east resize hot
zones. One shared reservation every caller had to know about produced a
recurring class of asymmetric-right-inset bugs instead: it was zeroed
piecemeal five times (FN-8766, mobile task detail, FN-8722, FN-8702, every
tablet window) while two callers leaned on it for their right inset and had to
restore it whenever one of those predicates fired. Delete the gutter, its five
overrides, and GitHub Import's borrowed-inset compensation. Where a scrollbar
and a resize target actually collide, use FN-8766's outboard east targets.
Trade-off accepted by the operator; the ratchet test now forbids the gutter in
any stylesheet at any breakpoint.
- The hosted Set Up AI modal did not fill its window: its standalone
`height: min(85vh, ...)` rule ties on specificity with FloatingWindow's
`height: 100%` and won on source order, leaving ~60px of dead window surface
under the footer alongside the 16px gutter strip. Right gap 17px -> 1px,
bottom gap 62px -> 1px.
- The "Connect remote Fusion server" card keyed only on
`desktopMode !== "local"`, and `desktopMode` is undefined on web, so every
browser first-run led with a native-shell hand-off form. Now also requires
`host !== "web"`.
Verified: 165 dashboard test files / 5829 tests pass, eslint and
`tsc -p tsconfig.app.json` clean, and a container built from this tree shows the
panel flush at 1280x800 and as a symmetric full-screen sheet at 390x844 with no
remote-server card.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Thirteen modals set an `aria-label` that restates the role they already
carry. `FloatingWindow` renders `role="dialog"` and
`aria-label={ariaLabel}` on the **same element**
(`FloatingWindow.tsx:628` and `:631`), so `"Settings dialog"` is
announced as **"Settings dialog, dialog."**
Fixed at all 13 call sites, plus a guard so the next copy-paste fails
instead of shipping.
### Two independent lines of evidence
I found this by inspection. Then, chasing unexplained dashboard
failures, I hit `NodesView.test.tsx`:
```
Unable to find an accessible element with the role "dialog" and name "Add Node"
...
Name "Add Node dialog":
```
Two tests were already asserting the **correct** name and failing
because the product had drifted to add the suffix. So this is not a
style preference — it is a defect with pre-existing tests that were red.
**Those 2 failures go green here**, and they were among the ones I had
not yet accounted for.
### The guard was vacuous, and mutation is the only reason I know
My first version used one regex with `[^`"']*?` for the label body. It
passed. It was worthless.
Every real call site interpolates a translator call:
```jsx
ariaLabel={`${t("scripts.title", "Scripts")} dialog`}
```
Those inner **double quotes terminate the character class**, so the
pattern matched **none of the thirteen offenders**. It only matched
hand-written samples like ``{`Settings dialog`}`` that happen to contain
no quotes — which is exactly what I had put in the case table. Re-adding
the suffix to `ScriptsModal` in its original form left the suite
**green**.
Extraction is now structural (brace matching), and the case table
carries the real quote-bearing shapes, including the nested-brace
`NodeDetailModal` form and the `+ " dialog"` concatenation variant.
**Mutation now behaves:**
| state | result |
|---|---|
| clean tree | 13/13 pass |
| suffix re-added to `ScriptsModal` (faithful form) | **fails**, naming
the file and the offending value |
I would have shipped a guard that could not fail on the defect it was
written for. It is the same error the guard exists to prevent — a cheap
proxy standing in for the real measurement — so the reasoning is
recorded in the file rather than quietly fixed.
### Verified
- `NodesView` + `FloatingWindow` + the new guard: **110/110**, then
**13/13** for the guard after the rewrite
- `tsc -p tsconfig.app.json`: **0 errors** · lint clean · FNXC gate exit
0
- **No i18n key or default string changed** — all 15 `t()` keys
byte-identical across the diff; only the literal outside the call was
dropped, and the now-pointless `` {`${…}`} `` wrappers were unwrapped
### Not fixed here
`agent-modals-mobile` (2) and `core-modals-mobile` (1) still fail on
this branch — they fail identically on `main`, are CSS-structure
assertions unrelated to aria naming, and belong to the #2915
dead-`.agent-detail-overlay` family. Left alone deliberately rather than
bundled in.
No changeset: user-visible a11y correction with no API or setting
change, and the release-notes audience is operators. Say the word if you
want one.
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Adds fusion-react/no-nested-component-definitions, a custom rule in the house
style of the existing detached-spawn guard. A component declared in render is a
new element type every render, so React remounts its subtree on each parent
update and destroys focus, scroll, and local state.
This pattern shipped three times without review or tests catching it: FN-8606's
ModalShell left Planning Mode and Settings untypable, and MailboxModal's
ReplyContextExpandable collapsed expanded reply rows. Tests missed it because
fireEvent.change sets a value without needing the node to stay mounted.
The rule reports PascalCase functions (including memo()/forwardRef()-wrapped)
that return JSX and are declared inside another JSX-returning function.
Lowercase render helpers are deliberately allowed — they are the sanctioned fix.
Escape hatch: // nested-component-allowlist: <reason>.
Scoped to production .tsx, with a vitest guard for the rule itself. Hoists the
two pre-existing violations (ProviderStatusBadge, GitHubStatusBadge in
ModelOnboardingModal) to module scope so the rule lands clean at "error".
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
window.open after awaiting /auth/login can outlive Chromium's transient
user activation and get silently popup-blocked in the desktop app — the
OpenAI Codex flow (method select + localhost callback server) crossed
that threshold while Anthropic's faster flow usually didn't, so Codex
login never opened the browser. Add a shell:openExternal IPC bridge
(http/https only), expose it in preload, and route every dashboard
auth-URL open through an openExternalUrl helper that falls back to
window.open on the web.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Placed directly after the Anthropic subscription and before the API-key
options; previously reachable only under Advanced.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- AI Setup: connected providers now render first; 'Skip for now' hides
once a provider is connected; footer buttons share one size.
- GitHub step: state-driven (no install/pitch content when connected),
one type scale, real <code> literals, per-OS gh instructions behind a
disclosure, single skip affordance; gh/OAuth status revalidates on
window focus and OAuth relogin so later steps stop showing stale
'not connected'.
- Project step: onboarding-driven opens keep 'Step 3 of 5' context;
runtime-node picker no longer lists 'Local node' and 'local (local)'
duplicates and hides itself when only the local node exists;
isolation-mode cards no longer render a stretched native radio or
uppercased descriptions.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Fixes the onboarding/settings GitHub step so it never offers a dashboard OAuth login for github (no github OAuth provider is ever registered; pi only ships anthropic/github-copilot/openai-codex), replacing the broken Connect OAuth button with gh CLI guidance and a clearer server-side error.
- Remove the "Connect OAuth (optional)" button and its login-instructions panel from the onboarding branch that runs when hasGithubProvider is false (ModelOnboardingModal.tsx), since it always called handleLogin("github") against a non-existent provider
- Update ModelOnboardingModal tests to cover the new gh-CLI-only flow
- Make POST /api/auth/login return a clear, actionable 400 naming the requested provider, the registered dashboard OAuth providers, and that GitHub integration uses gh CLI/token auth instead of a generic "Unknown provider" / model-not-found error
- Add routes-auth.test.ts coverage for the improved unknown-provider error message
- Add a patch changeset documenting the fix
Files changed:
.changeset/fn-7624-github-onboarding-auth.md | 7 +++++
packages/dashboard/app/components/ModelOnboardingModal.tsx | 32 +++++++---------------
packages/dashboard/app/components/__tests__/ModelOnboardingModal.test.tsx | 32 +++++++++++++++++++++-
packages/dashboard/src/__tests__/routes-auth.test.ts | 22 +++++++++++++++
packages/dashboard/src/routes/register-auth-routes.ts | 14 +++++++++-
5 files changed, 83 insertions(+), 24 deletions(-)
Fusion-Task-Id: FN-7624
Fusion-Task-Lineage: e7be1b0a-6e50-479d-b56e-1284e8a94b7f
Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
First-run project setup surfaced a blocking "Agent with this name already exists" error when creating
the default CEO. The default first agent can be created from more than one first-run surface (the
unified ModelOnboarding agent step and the project-setup SetupWizard sub-flow), and agent names are
unique per store, so the second create returned 409. The step's goal — a first agent exists — was
already satisfied, so both onboarding surfaces now treat a name collision as success and advance
instead of blocking. The user still creates the agent; they just aren't punished for the flow offering
it twice.
Separately, the desktop header "Desktop local mode / Switch server" button did nothing: main relays
the click as a `shell:open-connection-manager` IPC (webContents.send), but the preload never forwarded
it to the `window` DOM event ShellContext listens for, so the signal was dropped. Add the preload
bridge so the button opens NativeShellConnectionManager (Local/Remote toggle + remote-server profiles),
letting operators switch between running locally, connecting to a remote server, or a different remote.
Regression tests: SetupWizard advances on an already-exists agent; preload dispatches the window event
on the IPC.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
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>
Migration (multi-agent sweep over 216 files, 60 batches):
- Every user-visible dashboard + TUI string moved to t() with the exact
English inline default (en rendering byte-identical)
- Catalogs merged from per-batch fragments: en/zh-CN/zh-TW/fr/es now
carry ~5,930 keys each across common/app/errors/cli namespaces;
CLI bundles regenerated (6 locales incl. ko)
Integration fixes:
- 18 type errors: reserved {{count}} interpolations renamed, malformed
plural call, hand-rolled t-param types replaced with TFunction<"app">
- 23 lint errors: superseded label constants/helpers removed
- ExecutorStatusBar hook-order violation (keyboard-open early return
moved below hooks)
- TUI tests wrapped in I18nextProvider (uninitialized fallback renders
literal {{placeholders}}); dashboard vitest.setup boots a minimal en
i18next instance for the same reason
Known WIP (next commits): ~457 residual strings across 50 batches,
Korean drafts for swept keys, and a dashboard test-suite pass that is
still being stabilized (~283 failures under investigation — fake-timer
waitFor interaction, likely stale node_modules vs merged lockfile).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Adds user-facing warnings before OAuth login flows in both onboarding and settings, surfacing that manual code authentication is available as an alternative, with corresponding documentation updates and test coverage for the new warning UI.
Fusion-Task-Id: FN-4160
Merges shell multi-profile support for desktop (FN-3403) — spanning new connection-manager flows, shell onboarding interoperability, mobile connection profiles, desktop IPC/shell-settings plumbing, and tokenized titlebar styles — with a secondary migration of the WhatsApp plugin to the Baileys pairi
Fusion-Task-Id: FN-3403
Merges FN-3396's full Cursor CLI provider integration (Steps 1–4): defines a CLI-backed provider contract, adds the `fusion-plugin-cursor-runtime` plugin package with process management and runtime probes, wires dashboard auth flows and UI (ProviderCard, onboarding modal, settings), and bundles the
Fusion-Task-Id: FN-3396
Documents the static slot-host rendering contract in `docs/PLUGIN_AUTHORING.md`, clarifying how plugins should interact with the rendering system.
Fusion-Task-Id: FN-3260
Documents research recovery semantics in the CLI reference and settings reference, adding 9 lines of documentation across both files.
Fusion-Task-Id: FN-3014
This merge introduces a droid runtime plugin system with event bridge and process management (FN-3228), stabilizes plugin workspace verification gates and suppresses placeholder plugin shells in onboarding/settings flows (FN-3071), tokenizes danger/error styling in task detail components (FN-3350),
Fusion-Task-Id: FN-3071
This merge adds a changeset for feature FN-3349 (in-review retry behavior) and delivery documentation to the `@runfusion/fusion` package.
Fusion-Task-Id: FN-3349
This merge incorporates UI enhancements for the planning mode modal and quick chat FAB, moves the drag handle into provider actions, wires required plugin slot mounts, and adds tests for MobileNavBar and UsageIndicator components. The changes span the dashboard UI components with styling and behavio
Fusion-Task-Id: FN-3068
Merge brings FN-3067 UX revisions across onboarding components, including reduced ModelOnboardingModal complexity, new fallback styling for PluginSlot, and polish to OnboardingDisclosure, OnboardingResumeCard, and PostOnboardingRecommendations with minor updates to PlanningModeModal and SettingsModa
Fusion-Task-Id: FN-3067
Merged feat(FN-3059) which aligns provider metadata and documentation across the codebase, updating README and getting-started docs plus refinements to the CustomProviderForm and ProviderIcon dashboard components.
Fusion-Task-Id: FN-3059
This merge lands v0.12.0 with two major features: a droid-cli provider integration adding auth routes, status endpoints, and a settings toggle hook for controlling CLI-based authentication, plus a new experimental agent onboarding modal with a create-agent form. The release also stabilizes engine st
Fusion-Task-Id: FN-2981
Adds a new Droid CLI provider card to the onboarding flow, including a dedicated provider icon, simplified card CSS, and token fallback fixes for droid provider authentication. The changes wire the card into the ModelOnboardingModal and add test coverage for the card component, icon, and onboarding
Fusion-Task-Id: FN-2980
This merge introduces a new `packages/droid-cli` package that bridges AI agent execution as a subprocess, including process management, event streaming, tool mapping, MCP configuration, and thinking-mode support. It also adds the `DroidCliProviderCard` dashboard UI component with onboarding flows an
Fusion-Task-Id: FN-2978
This merge implements a recoverable pending-login auth flow (FN-3047) across three phases: cancellable in-progress auth routes in the API, an extended auth client contract, and updated ModelOnboardingModal/SettingsModal UI with proper cancel-button visibility during logout. It also adds `dashboard-r
Fusion-Task-Id: FN-3047
