### Preflight Checklist - [X] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet - [X] This is a single feature request (not multiple features) ### Problem Statement In the Claude desktop app, the in-app Browser is available in local sessions but not in SSH remote sessions. This leaves a clear gap in the remote workflow: - **Feature parity:** In most other respects SSH sessions ma

[FEATURE] Desktop: in-app Browser in SSH remote sessions

Status Open

Maintainer reply None cached

Activity 3 comments · opened Sep 28, 2026

Preflight Checklist

[X] I have searched existing requests and this feature hasn't been requested yet
[X] This is a single feature request (not multiple features)

Problem Statement

In the Claude desktop app, the in-app Browser is available in local sessions but not in SSH remote sessions. This leaves a clear gap in the remote workflow:

Feature parity: In most other respects SSH sessions match local sessions. The Browser is the most visible exception.
The pages don't depend on the remote host: Pages like GitHub issues and PRs, CI results and documentation have nothing to do with where the code runs, so whether the Browser is available shouldn't depend on the session type.
A core workflow, not an edge case: For code on GPU servers, HPC clusters or cloud VMs, an SSH session is the only way to work, so these users get a reduced version of the app.
Context switching: Every time I need to check an issue, a PR or the docs, I have to leave the app and come back. This is the friction the in-app Browser was built to remove.

Proposed Solution

Make the in-app Browser available in SSH remote sessions and have it behave as it does in local sessions: open it the same way (Views menu or keyboard shortcut), keep it beside the conversation, and load any web page while the session stays connected to the remote host.

Alternative Solutions

A separate browser window: Works, but means constant switching between windows.
A local session opened just for the Browser: Splits one task across two sessions.

Priority

Medium - Would be very helpful

Feature Category

Other

Use Case Example

I open an SSH session in the Claude desktop app to a lab GPU server, where the project lives.
While Claude edits the code, I need to check the related GitHub issue, review a PR and look up library documentation.
With this feature, I would open all of them in the in-app Browser beside the conversation, as in a local session.
The whole task stays in one window instead of being split between the app and a separate browser.

Additional Context

Related: #27381 (closed as stale, now locked). That report was limited to previewing a dev server started on the remote host. This request is for the general in-app Browser in SSH sessions.

View original on GitHub ↗

3 Comments

fanjules · 9 days ago

I can second this... absolutely critical for anybody running remote sessions (I'm doing so in a Linux VM for safety).

mbkkong · 6 days ago

I hit the same thing on Claude Desktop for macOS and patched it locally to see what blocks it. The change turned out to be small, so I'm sharing it here in case it helps the team ship it properly.

It's gated in two places. In the main process, the "Claude Browser" internal server's isEnabled checks sessionType==="ccd"&&!e.isSSH, so SSH sessions never get the mcp__Claude_Browser__* tools. Without that check the tools work fine from SSH.

In the renderer (Contents/Resources/ion-dist), three conditions allow the Browser only for a local session with no remote kind, and SSH sessions are local-type with remoteKind: "ssh". They decide the Browser button in the header, the pane shortcut, and the hook that binds the session's Browser context when the pane opens. If you fix only the first two, the pane opens and spins on "Setting up preview" forever. Adding || session?.type === "local" && browserAvailable to each of the three fixes it.

The pane still runs on the Mac, so it reaches public sites, Tailscale and LAN addresses, and localhost on the SSH host stays out of reach. For GitHub, docs, CI and dashboards that's all I need. The tools and links have worked from my SSH sessions since late September (now on 2.19675.0). The third renderer fix is from today, so I've only checked it on a patched copy so far.

Doing this locally has a real cost: the app has to be re-signed ad-hoc, so auto-update stops and macOS asks for Keychain and Local Network access again after every update. That's why I'd much rather see it in the app itself.

If someone wants to try it meanwhile, this is roughly the prompt I gave Claude Code. Run it in a local session, at your own risk.

<details><summary>Prompt</summary>

Enable the Browser pane in SSH sessions of Claude Desktop on macOS. Work on a copy
(cp -Rc /Applications/Claude.app) and keep the original as a backup.

1. In Contents/Resources/app.asar, find the "Claude Browser" server's isEnabled
   (search for ("launchEnabled")!==!1||) and make its !x.isSSH check always true
   without changing the length, e.g. rename isSSH to isSSX.
2. Update that file's SHA-256 and block hashes in the asar header, and put the new
   header hash into Info.plist under ElectronAsarIntegrity.
3. In Contents/Resources/ion-dist/assets/v1/*.js, find the three conditions that allow
   the Browser only for local sessions without a remote kind: the header pane buttons,
   the pane shortcuts, and the hook near .pendingPreviewLinkUrl that binds the Browser
   when the pane opens. Add ||session?.type==="local"&&<browser available variable>,
   reusing variables already in scope.
4. Re-sign the copy ad-hoc inside out, check it with codesign --verify --deep --strict,
   then swap it in.
5. Test from an SSH session: the Browser button shows, the pane loads, and navigate
   opens a page.

</details>

@addyosmani sorry for the direct ping. You asked for feedback when you joined, so here is mine: this one matters a lot. Many of us run Claude Code over SSH on home servers, GPU boxes and VMs, and the Browser is the one big thing still missing there. The fix looks like a few conditions on your side. Could you take a look, or pass it to the right person? Thanks a lot.

fanjules · 5 days ago

4\. I hit the same thing on Claude Desktop for macOS and patched it locally to see what blocks it. The change turned out to be small, so I'm sharing it here in case it helps the team ship it properly.

This is great work! I'm not brave enough to tinker with my own setup and am on Windows, but I hope the devs now resolve this issue so we can finally use the browser.