[BUG] "Enter: open GitHub issue" after /bug and /feedback silently does nothing when no browser can be opened

What's Wrong?

After /bug or /feedback, the last screen says "Thank you for your report!" and offers enter → "open GitHub issue". Pressing Enter does nothing observable: no browser opens, no error appears, no URL is printed, and the dialog closes with the status line "Feedback / bug report submitted".

The feedback itself does reach Anthropic — that part works. What is lost is the pre-filled GitHub issue, which contained the bug description, the environment block and the session context. There is no way to tell from the terminal that the hand-off failed, and no way to recover the URL afterwards: it is not printed, not logged, and not written to any file. From the user's side, "your browser opened it, go look" and "it was silently discarded" are indistinguishable.

What Should Happen?

Either the browser opens, or Claude Code says it could not open one and prints the URL so the hand-off can be completed by hand. Best of all, print the URL in both cases — it costs nothing when the browser does open, and it is the whole fix when it does not.

Error Messages/Logs

(none)

There is no output at all. That is the substance of the report: no error, no warning, and nothing in the transcript.

Steps to Reproduce

Preconditions — this needs an environment where a browser genuinely cannot be opened. Any one of these is enough:

• Linux with no graphical session, i.e. DISPLAY and WAYLAND_DISPLAY both empty (a container, an SSH session, WSL without a browser bridge), and no xdg-open installed.
• BROWSER set to a command that silently succeeds without doing anything, the most common being BROWSER=true.
• A Claude Code background session, which lands in the second case without the user configuring anything, because Claude Code sets BROWSER=true for background sessions itself.

Steps, as I hit it:

1. Start Claude Code with BROWSER=true claude. (A Claude Code background session reproduces this with no setup at all, since it sets BROWSER=true for itself — but the explicit form above is the one to try first, because it needs nothing but a shell.)
2. Run /feedback (or /bug).
3. Type any description and press Enter.
4. Press Enter through the scope and consent screens to submit.
5. Wait for "Thank you for your report!" with the hint enter → "open GitHub issue".
6. Press Enter.

Observed at step 6: the dialog closes and prints "Feedback / bug report submitted". Nothing else happens. Expected: a browser opens, or the URL is printed.

To confirm nothing was launched rather than a browser opening somewhere invisible, BROWSER=true can be swapped for BROWSER=/path/to/logging-wrapper.sh — the wrapper is invoked with the URL, so the URL does exist and is simply thrown away.

Metadata for the template fields

• Claude Model: not relevant — this is a UI path, reproduced on Opus.
• Is this a regression? I don't know. The same code shape is present in 2.1.243, 2.1.245 and 2.1.246, the three versions I have locally, so it is not new in 2.1.246. I have no older versions to check.
• Claude Code Version: 2.1.246 (Claude Code), build 1ba9d22, 2026-08-25.
• Platform: Anthropic API.
• Operating System: Ubuntu/Debian Linux — Ubuntu 26.04 LTS, aarch64, inside a VS Code dev container.
• Terminal/Shell: VS Code integrated terminal; background session (claude bg-pty-host).

Additional information

Why a background session hits this without the user doing anything

Claude Code sets BROWSER=true itself when it launches a background session. Two places in the 2.1.246 bundle add the same literal block: CLAUDE_CODE_SESSION_KIND:"bg", CLAUDE_BG_BACKEND:"daemon", FORCE_COLOR:"3", COLORTERM:"truecolor", BROWSER:"true". Reading the live process environment confirms it (tr '\0' '\n' < /proc/<pid>/environ on claude bg-pty-host contains those five values, alongside the inherited container environment). Nothing in my dev container sets BROWSER.

true is a real program whose entire job is to ignore its arguments and report success, so a caller that only checks whether the command succeeded will always believe the browser opened.

Setting a no-op browser for a detached session is a reasonable thing to want. The trouble is that true expresses it as "pretend it worked" rather than "there is no browser here", and every caller downstream believes it.

One consequence worth knowing when trying to reproduce this: when a client attaches to a background session, the session adopts whatever browser the client reports, and a client with no BROWSER of its own causes the variable to be deleted; detaching restores true. So BROWSER flips between true and unset depending on attach state, with nothing changing on the machine. Both states fail, but by different internal routes, which is why this can look intermittent.

What the code does (traced through the minified bundle, not source)

The Enter handler builds the URL and hands it to the link-opening function, then discards the answer — the call is not awaited and its boolean result is unused, with no error handler. The success line prints unconditionally afterwards.

The link-opener is not the problem: it already distinguishes six outcomes (no display, opener missing, non-zero exit, timeout, spawn error, invalid URL) and returns them. All six are dropped at the call site. That is why the two very different preconditions above produce identical silence, and it means the bug is not confined to no-op-BROWSER setups — on headless Linux the opener correctly reports "no display" and that is discarded too.

There is already a helper in the same module as the opener whose job is to answer "can a browser actually be opened here?", and it explicitly treats a BROWSER of true as "no". The MCP server OAuth flow uses it the way I would expect: it checks first, logs the URL, skips the pointless open, and awaits the call when it does make it. The /bug module imports the opener from that module but not the helper. So this is two parts of the codebase disagreeing, with a working precedent for the correct behaviour already in the tree.

Search strings to locate the three sites in unminified source, since minifier aliases will differ: action:"open GitHub issue" for the handler, reason:"no_display" for the opener module, Skipping browser open (headless environment) for the flow that gets it right.

Suggested fix, in order of value

1. Print the URL to the terminal alongside the "opening…" message, unconditionally. This fixes the report on its own, survives whatever the opener does, and is useful even when the browser opens normally.
2. Await the open and act on its result — surface the reason when it fails instead of discarding it.
3. Call the existing can-a-browser-be-opened helper before attempting the open, as the MCP OAuth flow does, so a no-op BROWSER, a missing display or a missing opener all report "here is the URL" rather than nothing.

Scope beyond /bug

At least one other module imports the same opener without the helper and without checking the result, so /bug and /feedback are unlikely to be the only affected commands — just where it was noticed. Worth a sweep of the opener's callers rather than a fix to this one screen.