Turning off "Run a local gateway" shows a default-port crash page on restart instead of a remote crew config/selection page

[buluoray]

What

When the "Run a local gateway" setting is turned off, the next restart lands on a crash / error page stating that no port is connected on the default gateway port, instead of routing the user to their Remote Crew(s).

Because the local gateway is intentionally not running, there is nothing listening on the default local port — so the app treating "default local port unreachable" as a fatal crash is the wrong behavior. The user is left staring at a dead-end error screen with no obvious path to their remote crews or to setting one up.

This is wrong in both states:

1. Remote crews already configured → should land on a remote crew selection page, not a crash page.
2. No remote crews configured → should land on a remote crew setup page that guides the user to add one, not a crash page. This second case is the more damaging one: the user has turned off local, has nothing remote yet, and the app dead-ends with a port error instead of the exact setup flow they need.

Why

This is a bad UX for anyone running in remote-only mode (e.g. gateway on a dev-dsk via Amazon Tunnels, with "Run a local gateway" turned off). The app already knows "Run a local gateway" is off by user choice, so a "local port not connected" state is expected, not an error. Surfacing a crash page — especially when no remote crew exists yet — makes the feature feel broken and hides the very configuration the user needs to make it work.

Expected behavior

When "Run a local gateway" is off, the app should never show the default-port crash/no-connection page. Instead:

• If one or more remote crews are configured: show a clean Remote Crew selection page — list the configured remote crews and let the user connect to one, or add/edit a remote host.
• If no remote crews are configured: show a Remote Crew setup page (empty state) that walks the user through adding their first remote crew — host, port, connection details — rather than a port-connection error.

In short: treat a disabled local gateway as a first-class mode, and default the landing view to remote crew selection (populated) or remote crew setup (empty), depending on config state.

Additional Context

• Repro (configured): turn off "Run a local gateway" with a remote crew set up, then restart → crash page instead of the selection page.
• Repro (unconfigured): turn off "Run a local gateway" with no remote crew configured, then restart → crash page instead of a setup flow.

[github-actions]

Automated triage summary — generated from the issue text alone, before any maintainer has read it. Treat every line as a starting point, not a verdict.

With the "Run a local gateway" setting disabled, restarting the app lands on an error page saying nothing is listening on the default local gateway port, instead of a remote-crew selection view. The reporter says this happens both when remote crews are already configured and when none are, leaving no path to add one.

Worth adding

• the app version and platform (desktop build/OS) where this occurs
• a screenshot of the error page and any error text or stack it shows
• app/gateway logs from the failed startup
• how the remote crew is configured in the working case (e.g. host/port via Amazon Tunnels)

_{Posted by issue-summary.yml. The model had no access to the repository — it read only this issue and the titles of recent ones.}

[CrysisDeu]

🤖 Kiro Crew Auto-Pipeline [operator: CrysisDeu#0c98c3a2]: Routing to needs-investigation. The bug is real (local-gateway-off should never dead-end on a default-port crash page), but the requested behavior is two NEW landing surfaces — a remote-crew selection page and a remote-crew setup/empty-state flow — plus routing logic keyed off the local-gateway setting and remote-crew config state. That's product/UX design (what the selection and first-run setup pages look like, what connection fields they collect), not a mechanically derivable fix. A human should look at the desktop shell's startup routing where the port-unreachable error is raised and decide the remote-first landing flow.