`o` isn't queued

[KTibow]

Astro Info

Astro                    v6.0.0-beta.6
Vite                     v7.3.1
Node                     v24.10.0
System                   Linux (arm64)
Package Manager          pnpm
Output                   static
Adapter                  none
Integrations             @astrojs/mdx (v4.3.13)
                         @astrojs/sitemap (v3.7.0)
                         @astrojs/svelte (v7.2.5)

If this issue only occurs in one browser, which browser is a problem?

No response

Describe the Bug

If you press o and enter when Astro is still booting, it discards the input instead of queuing it. This forces you to wait for Astro to boot and only then press o to open the server.

This happens on Astro 5 and 6. It emits the warning [vite] No URL available to open in browser.

What's the expected result?

Handle all queued/buffered input once Astro boots.

Link to Minimal Reproducible Example

https://astro.new/minimal?on=stackblitz

Participation

• I am willing to submit a pull request for this issue.

[matthewp]

Triage bot, can you take a look at this and see if this can be fixed without too much effort?

[github-actions]

I was able to reproduce this issue. When o is pressed before the dev server finishes booting, server.resolvedUrls is null and Vite's default handler immediately emits [vite] No URL available to open in browser without queuing the action.

Fix: I was able to fix this issue. The fix overrides Vite's default o shortcut in Astro's customShortcuts array with a version that polls for resolvedUrls to become available before calling openBrowser(), so pressing o during boot is deferred rather than discarded. View Fix

Cause: bindCLIShortcuts() is called during setupContainer() (before viteServer.listen()), so keyboard input is active while resolvedUrls is still null. Vite's default o handler checks resolvedUrls synchronously with no queuing or retry mechanism, so it silently fails during the boot window.

Impact: Any user running astro dev who presses o before the server finishes booting (especially noticeable with content layer sync or slow plugin initialization) will see the warning and have to manually press o again after boot completes.

Full Triage Report

Triage Report: Issue #15433 — o isn't queued

Issue Summary

Title: o isn't queued
URL: #15433
Reporter environment: Astro v6.0.0-beta.6, Vite v7.3.1, Node v24.10.0, Linux (arm64), pnpm, static output, no adapter, integrations: @astrojs/mdx, @astrojs/sitemap, @astrojs/svelte

Bug description: If you press o and Enter when Astro is still booting (during astro dev), the input is discarded instead of queued. This forces the user to wait for Astro to finish booting before pressing o to open the browser. The warning [vite] No URL available to open in browser is emitted. The reporter says this happens on both Astro 5 and 6.

Expected behavior: All queued/buffered input should be handled once Astro fully boots. Pressing o during boot should queue the "open browser" action and execute it once the server URL is available.

Reproduction Status

REPRODUCED: YES

Environment Details

• Astro: HEAD (monorepo, development build)
• Vite: 7.3.1
• Node.js: v24.13.0
• Platform: Linux (x64, CI)
• Package Manager: pnpm v10.28.2

Steps to Reproduce

1. Start astro dev (or equivalently, create a Vite server with createServer())
2. Before the server has called listen() and resolved its URLs, press o + Enter
3. Observe that the warning [vite] No URL available to open in browser is emitted
4. The browser does NOT open, and the action is NOT queued for later execution

Reproduction Details

We reproduced this programmatically by directly calling server.openBrowser() at two stages:

Before server.listen():

• server.resolvedUrls is null
• server.openBrowser() immediately logs the warning: "No URL available to open in browser"
• The action is NOT queued or retried

After server.listen():

• server.resolvedUrls is populated (e.g., {"local":["http://localhost:24891/"],"network":[]})
• server.openBrowser() works correctly with no warnings

Baseline verification:

After server.listen(), openBrowser() works without any warnings, confirming the issue is specifically about timing — the o shortcut handler doesn't queue or defer the action when URLs aren't yet available.

Root Cause Analysis

The bug lives in Vite's code, specifically in the openBrowser() method of the dev server. Looking at the relevant code paths:

Vite's openBrowser() implementation (in vite/dist/node/chunks/config.js around line 25492):

openBrowser() {
    const options = server.config.server;
    const url = getServerUrlByHost(server.resolvedUrls, options.host);
    if (url) {
        const path = typeof options.open === "string" ? new URL(options.open, url).href : url;
        // ... pre-transform optimization ...
        openBrowser(path, true, server.config.logger);
    } else server.config.logger.warn("No URL available to open in browser");
},

The issue is clear: openBrowser() checks server.resolvedUrls synchronously. If it's null (which it is before listen() completes), it emits the warning and does nothing else. There is no queuing, deferring, or retry mechanism.

Vite's bindCLIShortcuts and the o key handler (around line 16632):

{
    key: "o",
    description: "open in browser",
    action(server) {
        server.openBrowser();
    },
},

The o shortcut simply calls server.openBrowser() — there is no wrapper to check if the server is ready first.

Keyboard shortcut binding in Astro's dev server (packages/astro/src/core/dev/restart.ts lines 214-232):

Astro disables Vite's r, u, c shortcuts and adds its own s shortcut, but does NOT override or modify the o shortcut. The o key uses Vite's default handler.

Timing of shortcut binding:

bindCLIShortcuts() is called in Astro's createRestartedContainer() at packages/astro/src/core/dev/restart.ts line 229, which happens after the Vite server is created but the readline interface starts listening for input immediately. If Astro takes time to boot (content layer sync, plugin initialization, etc.), the o keypress can be received and processed before URLs are resolved.

Potential Fix Approaches

Approach 1: Fix in Astro (override o shortcut with queuing)

Astro could override the o shortcut in its customShortcuts array with a version that checks if resolvedUrls is available, and if not, waits for a server.listen event or polls until it becomes available.

Approach 2: Fix in Vite (upstream)

The openBrowser() method in Vite could be modified to queue the action if resolvedUrls is not yet available, executing it once listen() completes. This would be the most proper fix but requires an upstream PR to Vite.

Approach 3: Fix in Astro (delay shortcut binding)

Astro could delay calling bindCLIShortcuts() until after the server is fully ready with resolved URLs. However, this would also delay other shortcuts like q (quit) and h (help), which is not ideal.

Recommended approach: Approach 1 is the most pragmatic — it's a small change in Astro's codebase that doesn't require upstream changes to Vite.

Relevant Code Locations

• Astro shortcut setup: packages/astro/src/core/dev/restart.ts:214-232
• Astro preview shortcut setup: packages/astro/src/core/preview/static-preview-server.ts:52-64
• Vite's openBrowser() method: packages/astro/node_modules/vite/dist/node/chunks/config.js:25492-25503
• Vite's o key handler (dev): packages/astro/node_modules/vite/dist/node/chunks/config.js:16632-16638
• Vite's o key handler (preview): packages/astro/node_modules/vite/dist/node/chunks/config.js:16658-16665
• Vite's bindCLIShortcuts: packages/astro/node_modules/vite/dist/node/chunks/config.js:16569-16614
• Astro vite logger filtering: packages/astro/src/core/logger/vite.ts:20-59
• Astro dev container config: packages/astro/src/core/dev/container.ts:55-100

Error Messages

When pressing o before the server is ready:

[vite] No URL available to open in browser

Conclusion

This bug is confirmed and reproduced. The o keyboard shortcut calls server.openBrowser() which synchronously checks server.resolvedUrls. During the Astro boot phase (before listen() completes), resolvedUrls is null, so the action silently fails with a warning. The input is discarded rather than queued for when the server becomes ready. This is a UX issue that can be fixed in Astro by overriding the o shortcut to include a wait/queue mechanism.

---

Diagnosis (Instrumentation-Confirmed)

Instrumented Verification

Added console.log statements to packages/astro/src/core/dev/restart.ts (after setupContainer()) and packages/astro/src/core/dev/container.ts (inside startContainer()) to confirm the timing window. Running astro dev produced this output sequence:

[DEBUG-15433] bindCLIShortcuts called (shortcuts now active), but startContainer not yet called
[DEBUG-15433] resolvedUrls at this point: null
[WARN] [content] Content config not loaded
[DEBUG-15433] startContainer: about to call viteServer.listen()
[DEBUG-15433] startContainer: listen() completed, resolvedUrls: {"local":["http://localhost:34891/"],"network":[]}

This confirms that keyboard shortcuts become active (readline listening) while resolvedUrls is still null, and the URLs are only populated later when startContainer() → viteServer.listen() completes.

Exact Execution Flow

1. dev.ts:43 — createContainerWithAutomaticRestart() is called
2. restart.ts:147 — createContainer() creates the Vite server (no listen() yet)
3. restart.ts:234 — setupContainer() calls bindCLIShortcuts() at line 230, which creates a readline.createInterface({ input: process.stdin }) and starts listening for keyboard input immediately
4. restart.ts:235 — Function returns. resolvedUrls is null.
5. dev.ts:87-115 — Content layer initialization (MutableDataStore, syncInternal, contentLayer.sync, etc.) — this can take significant time
6. dev.ts:118 — startContainer() is finally called
7. container.ts:162 — viteServer.listen(port) is called, which populates resolvedUrls

The timing window is between steps 3 and 7. During this window, pressing o + Enter dispatches to Vite's default o handler which calls server.openBrowser(), which checks server.resolvedUrls synchronously, finds null, and emits the warning.

Root Cause (Confirmed)

File: packages/astro/src/core/dev/restart.ts
Lines: 214-234
What's wrong: The setupContainer() function (line 234) calls bindCLIShortcuts() (line 230) which activates keyboard input handling immediately. But the Astro dev server doesn't call startContainer() → viteServer.listen() until much later in dev.ts:118, after content layer initialization. Astro overrides shortcuts r, u, c, s but leaves Vite's default o shortcut, which has no queuing logic.

File: Vite's openBrowser() method (node_modules/vite/dist/node/chunks/config.js:25492-25503)
What's wrong: openBrowser() is a synchronous check — it reads server.resolvedUrls, and if null, emits a warning and returns. No queuing or retry.

File: Vite's o key handler (node_modules/vite/dist/node/chunks/config.js:16632-16638)
What's wrong: The o shortcut just calls server.openBrowser() without any readiness check.

Suggested Fix

Approach: Override the o shortcut in Astro's customShortcuts with a deferred version.

In packages/astro/src/core/dev/restart.ts, add an o shortcut to the customShortcuts array that waits for resolvedUrls to become available before calling openBrowser().

Confidence

Confidence: high

The root cause is fully confirmed via instrumentation. The timing window is clearly visible in the debug output and maps directly to the code flow. The fix approach is straightforward and low-risk.

---

Fix

FIX STATUS: SUCCESSFUL

What Was Changed

File: packages/astro/src/core/dev/restart.ts

The fix adds a custom o keyboard shortcut to Astro's customShortcuts array, overriding Vite's default o handler. The new handler checks if server.resolvedUrls is available:

• If URLs are available: Calls server.openBrowser() immediately (same as Vite's default behavior).
• If URLs are NOT available (server still booting): Polls every 100ms until server.resolvedUrls becomes non-null, then calls server.openBrowser().

Additionally, the type annotation for customShortcuts was narrowed from Array<vite.CLIShortcut> to Array<vite.CLIShortcut<vite.ViteDevServer>>, since we're in the dev server context and need access to openBrowser() which only exists on ViteDevServer.

Verification Results

1. TypeScript compilation: Clean — no type errors
2. Build: pnpm -C packages/astro build succeeded with 0 errors, 0 warnings
3. Unit verification: Custom test confirmed the built file contains the custom o shortcut override with resolvedUrls check, openBrowser call, and setTimeout polling mechanism
4. Regression test: test/astro-dev-headers.test.js — 3/3 tests passed

This report was made by an LLM. Mistakes happen, check important info.

[matthewp]

This is an upstream issue in Vite which is what handles the shortcut. Please report the issue there, thanks.

[KTibow]

Codex looked into this more closely and I think it's worth reconsidering.

Vite's openBrowser() does a synchronous check of server.resolvedUrls with no queuing or retry: if it's null, it warns and returns. Vite's CLI itself never runs into this because it always calls await server.listen() before binding shortcuts. So from Vite's perspective, openBrowser() is only ever called when the server is ready.

Astro's dev startup does it in the opposite order: shortcuts are bound in restart.ts before startContainer() is called, and viteServer.listen() doesn't happen until later in dev.ts → container.ts. That gap is where the o keypress gets dropped: it fires Vite's handler before resolvedUrls is populated.

So it's not that Vite has a bug — it's that Astro binds shortcuts earlier than its CLI does, which exposes a gap in the programmatic API that Vite's CLI never hits.

This is also pretty fixable on Astro's side. Edit: I think I have a clean fix, PRing soon