Repository navigation
vscode: 'Open Dev URL' row in the Workspace view (opens default browser) #780
Description
Context
Codev: Run Dev Server (workspace + worktree variants) spawns the dev
PTY inside VSCode, but the user still has to find the URL and open it
themselves. A one-click "open the running app" affordance, surfaced
right in the sidebar, closes that gap.
Proposal
Strictly manual — no auto-open, no settings, no lifecycle tracking.
- New optional config in
.codev/config.json, sibling to
worktree.devCommand:"worktree": { "devCommand": "pnpm dev", "devUrl": "http://localhost:3000" }
- New workspace-view row:
Open Dev URL, rendered immediately
below the existingStart Dev Server/Stop Dev Serverrow.
Visible wheneverworktree.devUrlis configured — independent of
whether the dev PTY is currently running (the row click should work
even if the server isn't up; the browser shows whatever the server
is or isn't serving, which is the user's call). - New command:
Codev: Open Dev URL. Backs the row click;
palette-visible for users who prefer keyboard. - Click behavior:
vscode.env.openExternal(vscode.Uri.parse(devUrl))
— uses the user's default browser (or whatever they've mapped via
workbench.externalUriOpeners).
Why default browser, not VSCode's Simple Browser
A real browser is the honest fit for a dev preview:
- DevTools / Console / Network / breakpoints / React DevTools — the
dev loop is overwhelmingly DevTools-bound, and Simple Browser has
none of them. - Real cookie jar. Simple Browser loads the target in an iframe inside
vscode-webview://, making it a third-party context; cross-site
OAuth / SSO can break because Chromium third-party cookie rules
block writes mid-flow. - No framing restrictions — sites with
X-Frame-Options: DENY/
strictframe-ancestors(auth providers, dashboards) render fine
in a real browser, blank in Simple Browser.
Users who specifically want embedded preview can still invoke Simple
Browser themselves via Command Palette → "Simple Browser: Show".
Why no auto-open
Considered and dropped: there's no API to detect whether the user
already has the URL open in their browser, and vscode.env.openExternal
always opens a new tab. Any auto-firing rule either piles up tabs (if
fired on every event) or guesses wrong (no signal to base it on).
Making the action manual sidesteps the whole class of problem and is
arguably what a developer wants anyway — explicit, predictable, no
surprises during dev-server restarts. The row is one click away, which
is the same cost as a clever auto-open without any of the footguns.
Acceptance
-
worktree.devUrlrecognized in.codev/config.json(validation
+ doc update). -
Codev: Open Dev URLcommand registered (palette-visible). - Workspace-view row "Open Dev URL" appears directly below the
Start/Stop Dev Server row wheneverworktree.devUrlis set.
Hidden when it isn't. - Click →
vscode.env.openExternal(devUrl)opens in the default
browser; works regardless of whether the dev PTY is running. - README updated with the new config block + the workspace-view
row.
Out of scope
- Auto-open on dev-server start (explicitly rejected — see rationale
above). - Embedded Simple Browser preview (deferred; not relevant to a
DevTools-bound dev loop). - Multi-URL dashboards (only the configured
devUrl). - Browser tab activation / "switch to existing tab" (not possible via
standard APIs; manual click is explicit by construction).
Activity
[-]vscode: open dev server URL in built-in Simple Browser[/-][+]vscode: auto-open dev server URL in default browser when dev server starts[/+][-]vscode: auto-open dev server URL in default browser when dev server starts[/-][+]vscode: 'Open Dev URL' row in the Workspace view (opens default browser)[/+]feat(vscode): "Open Dev URL" workspace row(s) via worktree.devUrl(s)
amrmelsayed commentedon Aug 14, 2026
Closing as shipped.
codev.openDevUrlis contributed inapps/vscode/package.jsonand implemented atapps/vscode/src/commands/open-dev-url.ts.apps/vscode/src/load-worktree-config.ts, sourced from Tower'sGET /api/worktree-config.One deliberate difference from the proposal here: the config key landed as
worktree.devUrls(an array of{ url }) rather than the singularworktree.devUrl, so a worktree can surface more than one dev URL. The behaviour this issue asked for (a manual, palette- and row-reachable "open the running app" action that works whether or not the dev server is up) is what shipped.