Add Startup settings: auto-connect to a host, open a new chat, last chat or terminal

[jankarres]

Getting from the app icon to a usable chat costs six taps and about seventeen seconds on every cold launch, and this brings it to zero for anyone who wants that. It adds a Startup section to "Settings" that decides two things about a launch: which host to connect to, and what to open once connected. Closes #62.

Both default to what the app does today, so nothing changes for anyone who does not open the page.

Switch auto-connect on and the second group wakes up. Agent and project appear only for the targets that need them.

The result, with Last used host plus New chat. Zero taps, where it used to be six.

cold-start.mp4

How it is put together

• lib/settings.ts gets a startup group next to server, editor and terminal, same defaults-plus-normalizer shape. That also handles migration, since an old settings file just gets the defaults filled in on the next read.
• lib/startupPlan.ts is the whole decision, pure and unit tested: settings plus live state in, a plan out. No I/O.
• state/startup.ts runs the sequence, connect, wait, resolve, open, with a cancel check at every await and a module-level hasRun so it can only ever fire on a cold start.
• components/StartupRunner.tsx renders null and just starts the thing. It sits in App.tsx rather than inside the provider, because the provider also wraps onboarding and the rule must not fire during first run.
• components/StartupBanner.tsx is the visible half, rendered by the Home tab in the slot OfflineBanner already uses.
• lib/navigate.tsx pulls the chat, sessions, git client, system monitor and ports pushes out of the seven components that each had a copy. The chat push alone carries eleven props, and I did not want the startup path to become one more place they have to stay in sync.

Behaviour worth calling out

The strip is cancellable, and leaving the Home tab cancels it too, since TabView unmounts the tab and the cleanup runs. That came free and is the behaviour you want anyway.

If the target cannot be reached, the app stays on Home and says why once. No fallback chain: opening a new chat because the last one is missing would be worse than doing nothing.

pickResumableSession sorts by updatedAt client-side rather than trusting the order the host sends. For a list a wrong order is cosmetic, but for "open the newest chat" it would quietly open the wrong conversation.

Two small things the navigate extraction changes rather than preserves. providerName now falls back from agent.title to agent.name before the raw id, where two of the old copies used the title alone and rendered an empty subtitle if a host reported none. And the ports page in the "More" tab is loaded dynamically now like every other page, because a static import inside lib/navigate.tsx would drag four pages into the initial bundle.

Testing

pnpm typecheck and pnpm format clean. pnpm test is 116 tests, up from 97, the new ones all on startupPlan. The production browser build compiles.

Ran end to end on the browser target against a real CLI host: each connect mode, the cold start above, cancel during connect, a tab switch mid-sequence, and both failure paths. Untested on Android and iOS, I did not set up the mobile build toolchain for this.

Before you merge

Two decisions you may see differently. Startup got its own settings category because it carries seven controls and governs the whole app rather than one surface, and the rule is global rather than per host, on the assumption that a phone tends to point at the same machine. Both are cheap to change.

If anything here should be different, conceptually or in the code, tell me and I will take care of it. Same if you would rather have it in smaller pieces: auto-connect with the Home target first, then lib/navigate.tsx and the five remaining targets.