Regression since v1.4.8: startup can enter a blank/partially empty TUI state before real data is ready

[CissiBot]

Description

Since v1.4.8, OpenCode can start into a blank or partially empty TUI state before the real UI elements appear.

Observed behavior:

• startup enters a mostly empty UI state
• models/providers/session/history elements appear later
• the effect is still reproducible in v1.4.11
• v1.4.7 does not show this behavior

Expected behavior:

• the startup UI should not enter a blank or partially empty intermediate state before real session/provider/workspace data is ready

Code analysis:

1. app.tsx changed startup routing so the app can enter a dummy session route early.

In v1.4.7, --session navigation was handled directly after mount:

if (args.sessionID && !args.fork) {
  route.navigate({
    type: "session",
    sessionID: args.sessionID,
  })
}

In v1.4.8, startup can instead enter an initial session route with sessionID: "dummy":

initialRoute={
  (input.args.sessionID || input.args.continue) && !input.args.fork
    ? {
        type: "session",
        sessionID: "dummy",
      }
    : undefined
}

This means the TUI can enter a session route before the real session data is ready.

2. sync.tsx changed ready() so the old loading gate is effectively disabled.

In v1.4.7:

get ready() {
  return store.status !== "loading"
}

In v1.4.8:

get ready() {
  return true
  if (process.env.OPENCODE_FAST_BOOT) return true
  return store.status !== "loading"
}

The unconditional return true makes the rest of the loading gate unreachable, so the UI can be considered ready before sync/bootstrap state is actually ready.

3. Together, these changes make it possible for the TUI to enter a session-like route too early, render while the real session/provider/workspace state is still not ready, and show a blank or partially empty intermediate state before the real elements appear.

Plugins

local plugin environment present

OpenCode version

1.4.11

Steps to reproduce

1. Start OpenCode
2. Wait for the UI to become usable
3. Observe that the UI first appears blank or partially empty, then fills in later

Screenshot and/or share link

Not provided

Operating System

Ubuntu 24.04.4

Terminal

Windows Terminal via WSL2

[github-actions]

This issue doesn't fully meet our contributing guidelines.

What needs to be fixed:

• The issue does not use one of the three required issue templates (Bug Report, Feature Request, or Question). Please re-submit or edit this issue using the appropriate template — this looks like it should be a Bug Report, which requires a ### Description field, steps to reproduce, version info, OS, and terminal details.

Please edit this issue to address the above within 2 hours, or it will be automatically closed.

---

This issue might be a duplicate of existing issues. Please check:

• After OpenCode starts, loading the model takes a relatively long time #23274: Very similar symptom (models not loading / blank UI state on startup after v1.4.8), explicitly referenced in your issue — consider whether this should be a comment there instead of a separate issue.

If you believe this was flagged incorrectly, please let a maintainer know.

[github-actions]

Thanks for updating the issue! It now includes all the necessary information — version details, steps to reproduce, and expected behavior. The compliance label has been removed.

[PandaSt0rm]

Seeing the same, also cannot send any messages until its actually loaded which can take forever in a massive repo - just did a full reinstall of WSL because I thought I had broken something developing a plugin

[CissiBot]

Seeing the same, also cannot send any messages until its actually loaded which can take forever in a massive repo - just did a full reinstall of WSL because I thought I had broken something developing a plugin

I suddenly encountered this problem today. Before that, I had been using version 1.4.7 with my own session plugin, so I also assumed it was caused by my plugin. It wasn’t until I noticed that the version number in the lower right corner had already changed to 1.4.11 that I asked Codex to analyze the updated code, which is why this issue came up.

[PandaSt0rm]

Yeah just downgraded to 1.4.7 and its totally fine again

[inschrift-spruch-raum]

Version 1.4.10 has the same issue.

[CissiBot]

Fixed in 1.14.17, so I’m closing this issue. If it is still reproducible, please add more details and reopen it.