Codex App restores stale discovered SSH host state on startup and crashes with "No AppServerManager registered for hostId"

Open 💬 1 comment Opened Apr 19, 2026 by HeMuling

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.415.40636 (1799)

What subscription do you have?

Pro

What platform is your computer?

Darwin 24.1.0 arm64

What issue are you seeing?

Codex App can get stuck restoring a stale discovered SSH host on startup.

In my case, the old discovered host ID was:

remote-ssh-discovered:192.168.195.80

After startup, the app tried to use that old host/project state even though it was no longer valid. This led to an internal error path and the app showed an error page.

Observed error:

No AppServerManager registered for hostId: remote-ssh-discovered:192.168.195.80

The UI then fell into an "Oops, an error has occurred" state.

What steps can reproduce the bug?

I cannot guarantee a minimal repro from scratch, but this is the state pattern that reproduced it on my machine:

  1. Use Codex App with Remote SSH / discovered SSH hosts.
  2. Have one or more remote projects associated with a discovered host ID like remote-ssh-discovered:<ip>.
  3. Later change/remove that host situation so the old discovered host is no longer valid.
  4. Restart Codex App.
  5. On startup, Codex restores previous remote project / host selection state.
  6. The app attempts to route requests to the stale discovered host ID and fails with No AppServerManager registered for hostId: ....

What is the expected behavior?

If persisted remote SSH state points to a stale or unavailable discovered host, Codex App should safely ignore or reconcile that state on startup.

It should not crash or show a fatal error page. It should fall back to a neutral state such as no active remote project, no auto-connect for the stale host, or a recoverable prompt asking the user to reselect a host.

Additional information

I investigated local persisted state and found the stale host was being restored from a local global state file rather than only the usual Application Support cache.

The stale references included data shaped like:

  • agent-mode-by-host-id["remote-ssh-discovered:192.168.195.80"]
  • remote-connection-auto-connect-by-host-id["remote-ssh-discovered:192.168.195.80"] = true
  • remote-cwds-by-host-and-workspace["remote-ssh-discovered:192.168.195.80"]
  • remote-projects[*].hostId = "remote-ssh-discovered:192.168.195.80"
  • active-remote-project-id

After clearing those stale references, the app started normally and no longer emitted:

  • remote-ssh-discovered:192.168.195.80
  • No AppServerManager registered for hostId: remote-ssh-discovered:192.168.195.80
  • Oops, an error has occurred

This suggests a startup reconciliation bug in persisted Remote SSH state, rather than an SSH config problem itself.

Suggested fix direction

On startup, if persisted remote host/project state references a discovered host that no longer has a registered app server manager, the app should:

  • drop the stale host binding
  • clear the active remote project selection for that host
  • disable auto-connect for that host
  • continue startup without surfacing a fatal error page

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗