fix(browser): treat no-op BROWSER values as unset so headless sessions can fall back#756
Merged
backnotprop merged 1 commit intoMay 19, 2026
Conversation
…s can fall back Claude Code's agent view (and similar background/headless environments) sets $BROWSER=true to mean "do not launch a browser." The previous logic took that literally and ran `true http://localhost:NNNN` via `Bun.$`, which exits 0 without opening anything. The server then sits forever in waitForDecision() with no visible UI and no way for the user to recover the URL. Detect the documented no-op sentinels (`true`, `false`, `none`, `:`, `0`, `1`) on both PLANNOTATOR_BROWSER and BROWSER and treat them as if the variable were unset. This lets shouldTryRemoteBrowserFallback() reach the VS Code IPC fallback in remote sessions and lets openBrowser() fall through to the platform default when nothing else is configured. Refs backnotprop#154.
Owner
|
Is this the fix for |
Owner
|
great work |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
When
$BROWSER(or$PLANNOTATOR_BROWSER) is set to a no-op sentinel liketrue,false,none,:,0, or1— as Claude Code's agent view does (BROWSER=true) —openBrowser()shells out viaBun.$and runs something equivalent totrue http://localhost:NNNN.true(1)exits 0 without doing anything, the function returns success, and the server then sits inwaitForDecision()forever. No browser appears, the URL isn't recoverable, and the session looks hung.This is the BROWSER-sentinel branch of the same family as #163 (which fixed
BROWSER=open/ VS Code devcontainer scripts). The remaining sentinel case still affects every headless / background runner that conventionally setsBROWSER=trueto disable browser launching.Fix
packages/server/browser.ts:isNoOpBrowserSentinel()recognising the documented no-op values (case- and whitespace-insensitive).openBrowser(), treat a sentinel-valuedPLANNOTATOR_BROWSER/BROWSERas if the variable were unset, so we fall through to the platform default (open/xdg-open/cmd.exe /c start) instead of shelling out to the sentinel.shouldTryRemoteBrowserFallback(), treat the same sentinels as "no real handler configured" so the VS Code IPC fallback still fires in remote sessions where it would otherwise be skipped.Net behaviour:
BROWSER=true(agent view)true http://...→ no-opBROWSER=/usr/bin/firefoxPLANNOTATOR_BROWSER='Google Chrome'(macOS)open -achromeopen -achrome (unchanged)No protocol or stdout changes, no new dependencies, no surface-area additions.
Tests
Adds
packages/server/browser.test.tscoverage:shouldTryRemoteBrowserFallbacknow returnstruewhenBROWSER/PLANNOTATOR_BROWSERare sentinels.isNoOpBrowserSentinelrecognises the documented values (incl.TRUE,none) and rejects real handlers (/usr/bin/firefox,Google Chrome,open).bun testis green (1167 pass / 0 fail).bun run typecheckis clean.Refs #154 (BROWSER-sentinel cause; other code paths in that issue may still apply).
Fixes #724