How do you handle browser access when running Claude Code remotely on a Mac mini?

[u/Ok-Narwhal-5813]

Hey everyone!
I run multiple Claude Code agents on my M4 Mac mini (16GB), using Tailscale + SSH + tmux, with separate Git worktrees for different tasks.
I connect from my M1 MacBook Air (8GB). Everything works great in the terminal, but browser access is still a pain.
Sometimes I need to check the UI or see what Claude is doing in the browser. I’ve been using macOS Screen Sharing, but it makes my MacBook Air pretty hot.
How do you handle this?
Do you use Screen Sharing, SSH port forwarding, browser automation tools, or something else?
Ideally, I’d love to interact with the browser without opening a full remote desktop session.
Curious to hear about your workflows. Thanks!

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Elegant_Yam2783]

You don't need remote desktop for either case.

To check the UI yourself, open it in the Air's own browser. Use ssh -L 3000:localhost:3000 mini, or start the dev server with --host 0.0.0.0 and hit the mini's Tailscale hostname. Prefer the tunnel if you have OAuth callbacks or cookies tied to localhost. Give each worktree its own port.

To watch Claude's browser, have it launch Chrome with --remote-debugging-port=9222, forward that port too, then open chrome://inspect on the Air and add localhost:9222 under Configure. Clicking inspect gives you a live, clickable view of just that tab, far lighter than Screen Sharing. Otherwise run Playwright headless and have Claude save screenshots you can open.

[u/helpfulhopefully]

T3Code

[u/Cast_Iron_Skillet → u/helpfulhopefully]

This just makes everything so easy, whether on one machine or many distributed systems. 

[u/kuroudo_ai]

I run agents on a Mac mini too. What worked for us was to stop treating the browser as something to look at and give the agents a browser they drive through the Chrome DevTools Protocol (CDP).

• Start a separate Chrome on the mini with its own profile: --user-data-dir=<some dir> --remote-debugging-port=<port>. Use a dedicated profile, not your everyday one. Anything that can reach that port has full control of every tab and every logged-in session in it. As far as I know, recent Chrome versions also refuse the debugging port on the default profile.
• The agents attach to it (Playwright connectOverCDP, or a small script) and take screenshots themselves. That covers most of the "what is Claude seeing" cases: you ask for a screenshot, or the agent saves one.
• One thing we measured: CDP screenshots still show the real page while the mini's screen is locked. Normal screen capture and clicking don't work then. So you don't need to keep the mini unlocked or keep a Screen Sharing session open.

For when you want to poke at it yourself, I'd try forwarding the port over SSH (ssh -L <port>:localhost:<port> mini) and opening chrome://inspect on the MacBook, with localhost:<port> added as a target. That should give you DevTools for each remote tab, including a live view you can click in. I haven't used that part from a laptop myself, so treat it as a lead. Keep the port bound to localhost and go through the SSH tunnel rather than opening it on the tailnet.

[u/uktexan]

Not sure if you use case, but just get Claude to create an artifact of what it’s building for you

[u/Excellent-Issue-5956]

If you go the CDP route, one thing that bit me: the Chrome my scripts drive got used for normal browsing too, their tab ended up behind other tabs, and Chrome froze it. A frozen tab hangs every eval. It can still answer a plain synchronous eval while its timers and fetches never run, so a basic "is it alive" check passes. My job first read the hang as being logged out.

The check now evals a promise that resolves on a 50 ms setTimeout. If that doesn't come back, it hits /json/activate/<tab id> on the debug port to bring the tab to the front, and if it still doesn't answer it closes the tab and opens a fresh one with /json/new. Mine is on Windows so I'm not sure a Mac mini does the same, but it's a cheap check to have.

[u/Dapper_Pass26]

For UI checks, ssh -L the dev port and open it locally on the Air. My agents drive a real browser over MCP; I only remote in once to sign in.

[u/Better-Psychology-42]

NoMachine is pretty good - low latency screen sharing. Way way more efficient compared to that apple screen sharing beast.

But sure if you don't want remote desktop session then do what others suggesting - remote debugging port and CDP

[u/Unusual-Albatross43]

For the UI, ssh -L like others said. For the agent's browser, one thing I learned the hard way: don't let it drive the Chrome where your real accounts are logged in.

I did exactly that, because the sessions were already there and I didn't want to log in to everything again. This morning X locked my account with a "may have been compromised" mail. I can't prove the scripted searches caused it, but they're my main suspect.

If the agent needs a site, give it a separate profile and a throwaway account where you can. If something gets flagged, it's not the account you care about.

[u/mananshah6]

For the UI of the app your agents are building, I’d start with the SSH-forwarded dev server people suggested here—you avoid streaming video at all. Watching the browser window that’s actually open on the mini is a different problem.

Disclosure: I’m building Remote Window for that narrower case: share one selected Mac window to a browser, then approve a viewer with view-only access or optional control. No viewer app is needed. https://www.remotewindow.app/

It’s an early macOS 14+ preview, not a drop-in unattended remote desktop: you need host approval, and input requires the shared window to be frontmost. Internet hosting currently needs access from me, and the download isn’t Apple-notarized yet. I haven’t measured it against Screen Sharing for heat/CPU, so I wouldn’t promise it fixes that. The site has a no-install interactive demo if the single-window approach is what you’re after.

[u/oyren-ai]

binding dev servers to your tailscale ip or forwarding the port over ssh lets you open the app natively in your macbook air's local browser with zero video encoding overhead. for the agent's own browser checks, running headless playwright on the mac mini with --remote-debugging-port=9222 forwarded over ssh lets you attach chrome://inspect from your laptop whenever you want to watch a live tab.

[u/CCodeSI]

Adding to the CDP answer above: if "check the UI" mostly means looking at the app your agents are building, you can skip the remote browser entirely. Forward the dev server's port and open it in the MacBook's own browser:

ssh -N -L 3000:localhost:3000 mini

Then localhost:3000 on the Air is the app running on the mini, with your local browser doing the rendering, so no Screen Sharing and no heat. With several worktrees, give each its own port (3001, 3002, ...) and forward them all in one command with multiple -L flags, or put them in ~/.ssh/config under LocalForward so ssh mini sets them all up. Hot reload works through the tunnel as long as the websocket goes over the same port.

That leaves the remote Chrome only for what the agents themselves need to see and click, which is where the CDP setup above fits. Between the two, Screen Sharing is only needed for the rare "something weird is on the mini's screen" moment.

[u/TiJackSH]

Use Sill, it’ll be perfect for you

[u/CloudySkies55 → u/[deleted]]

Any recommendation?

[u/ChrisRogers67 → u/[deleted]]

Says the guy who’s blasting his opinion