Run Claude Code From Any Browser: A Pinggy Devices Guide

Access to a real terminal from any browser is one of those superpowers that sounds too good to be true. You keep your workstation or server where it is, you leave a small agent running, and then from a laptop, tablet, or even a borrowed computer you open a browser tab and get a shell on that machine. Pinggy makes this workflow simple with its Devices feature. In this guide I will show you how to combine Pinggy Devices with Claude Code so you can run AI coding sessions remotely, inspect logs, restart services, and keep long tasks alive even after you close the browser.

The core idea is straightforward. You install the Pinggy CLI on a machine, connect to the Pinggy dashboard with one outbound connection, and then use that browser dashboard to open a terminal. Once the terminal exists, you can run claude or any other command line tool you would normally use locally. There is no SSH server, no open inbound port, and no public IP address to configure. For developers who work with AI agents, this removes a whole category of network headaches.

The Problem: AI Coding Agents Are Tied to Your Machine

Claude Code and similar coding agents are command line tools. They are great when you are sitting in front of your development machine. They can read your repository, edit files, run tests, commit code, and interact with APIs using your saved credentials. But once you step away, they become unreachable. Laptops sleep, office networks block inbound traffic, home routers use NAT, and cloud VMs may be locked down with security groups. You may want to start a long refactoring task and then check on it from another room or from a different city. The default tools, SSH and remote control features, have limitations.

SSH requires a server listening on port 22, a reachable IP address, and often a number of firewall changes. If the machine is behind a hotel router, a cellular connection, or a strict corporate firewall, inbound SSH is not an option. You can use a reverse tunnel, but tunnels need to be started, monitored, and sometimes restarted. Claude Code has a Remote Control mode, but it is for attaching to an already running claude process, and it requires someone or something to start that session first. Also, depending on your account tier, Remote Control may not be available at all.

This is where the terminal in browser model shines. The machine makes one outbound connection. The browser connects to a dashboard over HTTPS. The dashboard relays keystrokes and terminal output. No inbound network configuration is needed. In the rest of this post, I will walk through the complete setup using Pinggy Devices, then run Claude Code from a browser terminal, and cover the production details that matter when you trust a remote AI agent with real work.

What Pinggy Devices Actually Is

Pinggy Devices is a feature of Pinggy that turns any machine with the Pinggy CLI into a device you can manage from the Pinggy dashboard. The feature appeared in Pinggy CLI v0.6.2 on November 2, 2026. I tested the workflow with Pinggy CLI 0.6.3 and Claude Code 2.1.318 on an Apple Silicon MacBook. The limits and pricing details mentioned in this article are from the Pinggy Devices docs and the Pinggy pricing page, checked on November 3, 2026.

Unlike a traditional tunnel, Pinggy Devices does not expose a port on the public internet by default. Instead, the CLI registers the machine with your account and keeps a persistent channel to the dashboard. From the dashboard, you can open a shell on that machine. Each shell runs as the same user who started the Pinggy agent. That is a crucial detail: if you run pinggy device connect as your normal user, the browser terminal will have your home directory, your Git configuration, your SSH keys, your environment variables, and your Claude Code login. It is effectively you sitting at the machine, just rendered through a browser.

How the Architecture Works

Let us look at the moving parts before we jump into commands. Pinggy Devices is not a magic portal into your laptop. It is a relay between a browser based terminal client and a shell process on your machine. Here is the flow:

1. The Pinggy CLI on your machine establishes an outbound connection to the Pinggy infrastructure.
2. The CLI authenticates itself with a device token, which is stored locally after the first successful connect.
3. The Pinggy dashboard, which your browser loads over HTTPS, sends your keystrokes to the relay.
4. The relay forwards those keystrokes through the existing outbound connection to the CLI agent on the machine.
5. The agent starts or attaches to a shell, runs the commands, and streams the resulting terminal output back to the browser.

Because the connection is initiated by the machine, there is no need for a public IP, port forwarding, or a DMZ. The outbound connection can use standard HTTPS ports, which means it can pass through most firewalls and proxy environments. The browser side only needs access to the Pinggy dashboard, which is a normal website. This architecture is similar to remote support tools, but it is designed for developers who need full terminal access.

Prerequisites

Before you begin, make sure you have the following:

• A machine you can physically access at least once, such as a laptop, desktop, or VM.
• A user account on that machine with permission to run the Pinggy CLI. You do not need root.
• An email address for the Pinggy account. If you do not already have one, a new free account will be created when you enter the email and verification code.
• A browser that can reach the Pinggy dashboard. Chrome, Firefox, Safari, and Edge all work.
• Enough disk space and memory to run both the CLI and Claude Code. Claude Code is a Node.js application, and its typical install requires a few hundred megabytes.
• Optionally, npm and Node.js if you are on Alpine or another musl based Linux distribution, because the standard install script may not work there.

The install script does not require sudo. It installs the CLI into your home directory and runs the login flow automatically. On Windows, the PowerShell script uses irm and iex. On Alpine, the official docs recommend npm install -g pinggy instead.

Step 1: Install the Pinggy CLI and Sign In

The first command is simple. On Linux and macOS, open a terminal on the machine you want to reach and run:

curl -fsSL https://pinggy.io/install.sh | sh

The script will download the Pinggy CLI, put it in a location on your PATH, and start the login process. On Windows, use PowerShell:

irm https://pinggy.io/install.ps1 | iex

When the CLI asks for your email, enter the address you want to associate with the Pinggy account. It will send a six digit verification code. Type that code in the terminal. You may also be shown a link with an Approve sign in button. Only approve the login if the page on your screen displays the same code that the terminal printed. This prevents account takeovers from a mistyped email.

After the code is accepted, the CLI creates a device on your Pinggy account. The device name is usually the hostname of your machine. It appears on the Pinggy Devices page in the dashboard. If the machine was already added, the dashboard shows a Connect this device card on the Overview tab. That card contains two commands that already include your device token.

The first command works for machines that do not have the CLI installed:

curl -fsSL https://pinggy.io/install.sh | DEVICE_AGENT_TOKEN=<TOKEN> sh

The second command is for machines where the CLI is already installed:

pinggy device connect --token <TOKEN> --manage dashboard.pinggy.io

The --manage flag tells the agent which dashboard host it should connect to. The documentation for Pinggy Devices lists the same command without --manage, and it uses the default dashboard host. Using an explicit --manage is useful when you have multiple environments or when your company runs a custom relay. The token based flow is important for headless machines because you do not need to type an email or a verification code. You can install and connect in one step.

After the first successful connect, the CLI saves the token on the machine. From then on, you only need pinggy device connect to reconnect.

Step 2: Keep the Device Running in the Background

When you run pinggy device login or pinggy device connect for the first time, the agent stays in the foreground. It prints connection status, and it keeps running until you press Ctrl+C. For a quick test, that is fine. For real use, you want the agent to survive after you close the terminal. Stop the foreground agent, then reconnect in teh background with the -b flag:

pinggy device connect -b

If the machine does not have a saved token yet, include the token:

pinggy device connect --token <TOKEN> -b

The -b flag tells the CLI to run as part of the Pinggy daemon. The daemon is a lightweight background process that starts when you first run a background connect command. It is not the same as a cron job or a systemd service. It outlives the terminal that started it, but it does not survive a reboot. After the machine restarts, you must run pinggy device connect -b again to bring the device back online.

To stop the background agent, use:

pinggy device stop

If you want to stop the entire Pinggy daemon and all connected devices, use:

pinggy daemon stop

When the agent is stopped, the Pinggy dashboard shows the device as offline. If you try to open a terminal, the Terminal tab will be unusable until the device reconnects. You can also remove the device token from the local machine with pinggy device remove, but that only forgets the token locally. It does not delete the device from your account.

Step 3: Open the Terminal and Run Claude Code

Now the fun part. Go to the Pinggy dashboard, open the Devices page, and click the device you just connected. The Overview tab shows useful information about the machine: hostname, operating system, CPU, memory, and live system usage. This is handy for quickly checking whether the machine is under load before you start a big AI assisted refactor.

Above the system stats, you may see buttons for Terminal, Activity, and other tabs. Click Terminal and then click New shell. A new shell tab opens. Each shell gets its own tab, so you can have multiple terminals open at the same time, depending on your plan. From the browser, you can use the terminal almost exactly as you would use a local terminal. Typing, keyboard shortcuts, and terminal resizing work through the browser based client.

Let me show you a typical Claude Code workflow. You can change into your project directory and start the agent:

cd ~/code/storefront
claude

The first time you run claude in a browser shell, it may ask you to log in. If Claude Code is not installed yet, install it from the same browser shell:

curl -fsSL https://claude.ai/install.sh | bash

However, you should log in while you are still physically at the machine, because the first launch of Claude Code tries to open a browser window on the local machine. Claude Code has a fallback that prints a login URL and asks you to copy it, but I have not personally tested that fallback through the Pinggy dashboard terminal. If you want to be safe, complete the Claude Code login before you leave home.

Once Claude Code is running, the browser terminal behaves like a normal terminal. You can describe a task in natural language, approve file edits, run tests, and watch the output. The terminal redraws quickly enough for interactive work, and the dashboard keeps the session alive as long as you keep the shell active.

Here is what a simple Claude Code session looks like inside a Pinggy browser terminal. The shell on the right is running on the remote machine, while the browser is only responsible for drawing the terminal screen and capturing keystrokes.

Claude Code can also be used for non interactive tasks. You can ask it to generate a commit message, run the test suite, or fix a lint error. The browser terminal streams all of it back to you in real time.

After Claude Code finishes a task, it prints a summary of the files it changed and the commands it ran. You can review the output, type a follow up prompt, or switch to another shell tab.

Step 4: Run Long Tasks in the Background

A dashboard shell has two time limits. If the shell has no activity for 30 minutes, it ends. If the shell is open for 8 hours, it ends regardless of activity. This is intentional; it prevents forgotten browser tabs from leaving orphaned processes running forever. But it creates a problem for long Claude Code tasks, like running the test suite and fixing all failing tests in src/billing, or migrating a codebase from JavaScript to TypeScript. Those tasks can take longer than 30 minutes, and you might not be typing while they run. If the shell ends, the process running inside it may also end.

To handle long tasks, Claude Code has a background mode. You can start a session that is supervised by a seperate supervisor process, not by the terminal. The command looks like this:

claude --bg 'run the test suite and fix the failing tests in src/billing'

On Claude Code 2.1.317, running a short test prompt returned immediately and printed something like this:

Starting background service...

backgrounded · 5dc70293

  claude agents             list sessions
  claude attach 5dc70293    open in this terminal
  claude logs 5dc70293      show recent output
  claude stop 5dc70293      stop this session

The important thing is that a --bg session is not attached to the shell that started it. It runs in its own supervisor process, so it keeps working even if the dashboard shell closes. You can close the browser tab, go for a walk, and come back later. From any later shell, you can list all your sessions:

claude agents

You can reattach to a specific session with:

claude attach 5dc70293

You can view recent output without attaching:

claude logs 5dc70293

And you can stop a session:

claude stop 5dc70293

To detach from an attached session, press the left arrow key on an empty prompt, or press Ctrl+Z. A background session runs in its own Git worktree under .claude/worktrees/. This isolates the changes it makes from your main working tree until you merge them. The session survives sleep mode, but it stops if the machine shuts down. If you expect to run long tasks overnight, make sure the machine is plugged in and not set to hibernate.

Free vs Pro: What You Actually Get

The Pinggy browser terminal is available on every plan, including the Free plan. The differences are in the number of devices and concurrent terminals. The following numbers come from the Pinggy pricing page and the Pinggy Devices docs, as checked on November 3, 2026.

Plan	Price	Devices	Terminals per device	Terminals open across all devices
Free	$0	1	1	1
Pro	$2.50/month billed annually, $3/month billed monthly	25	3	10 per seat

The Free plan is enough for one home machine and one terminal. If you only need to run one Claude Code session from your laptop while you are away, that is fine. Once you start using multiple shells, the Pro plan becomes much more comfortable. Three shells per device means you can keep one terminal for Claude Code, one for a development server, and one for Git commands or log watching.

Pro also includes persistent tunnels, custom domains, and teams, and it comes with a 7 day free trial. For larger organizations, Enterprise offers custom pricing and unlimited devices and terminals. If you are trying to decide whether Free is enough, start with Free and only upgrade when you find yourself constantly closing and reopening shells.

How This Compares with Remote Control and SSH

There are two common alternatives for remote access to Claude Code. Both have trade-offs.

Claude Code Remote Control

Claude Code Remote Control is a feature that lets you attach to an already running Claude Code session. It is useful for pair programming or for checking in on a session that someone else started. However, it requires a Pro, Max, Ultra, Team, or Enterprise subscription. You cannot use it with API keys alone. More importantly, Remote Control only reaches a claude process that is already running. Someone still has to start claude remote-control on the machine before you can connect. If the machine is locked or the process dies, Remote Control cannot start a new one for you.

SSH and Reverse Tunnels

SSH is the classic answer. If the machine has a public IP and an SSH server, you can connect from anywhere. But many machines are behind NAT, CGNAT, or strict firewalls. To reach them, you need a tunnel like:

ssh -p 443 -R0:localhost:22 [e-mail]

That command creates a reverse tunnel through Pinggy's free TCP service, but the public address changes every 60 minutes on the free tier. You would need to keep checking the new address, which is impractical for interactive work. Tunnels are also a separate layer from the terminal; you still need an SSH client on the device you are connecting from.

What Pinggy Devices Changes

A Pinggy Devices shell has neither limitation. You can start Claude Code from scratch, restart a development server, run git pull, or even use a different coding agent like Codex. The browser terminal has your machine's credentials and filesystem, so it works like a local shell. There is no need to pre-start a special server. The only requirement is that the Pinggy agent is running on the machine.

If you want a deeper comparison of Claude Code and Codex on virtual machines, Pinggy has a separate guide that covers those setups in detail. The short version is that the device terminal gives you a generic shell, while Remote Control gives you a narrow window into one specific process.

Security Considerations

Giving yourself browser access to a machine also means giving anyone who can access your Pinggy account the same power. You should treat the Pinggy dashboard like a root password. The device token is stored in device.json under ~/.config/pinggy/, and it is readable only by your user. According to the Pinggy Devices docs, the agent never logs what you type. The Activity tab in the dashboard lists events with source IP addresses, so you can see when a device connected and from where.

The biggest risk is account compromise. Anyone signed in to your Pinggy account can open a shell on your devices, run commands as your user, and start Claude Code with your Anthropic login. That means they recieve access to your source code, environment variables, cloud credentials, and any API keys in your shell profile. Before you rely on this workflow, enable two factor authentication on your Pinggy account. Also, keep the dashboard's connect commands out of screenshots and chat messages, because they contain the device token. If a token leaks, an attacker can connect a rogue machine to your account or potentially take over your device.

To cut off a machine, delete the device in the dashboard or rotate its token. Rotating the token invalidates the old one, which forces the legitimate machine to reconnect with a new token. Note that pinggy device remove only forgets the token locally. It does not revoke the device from the account. Use the dashboard for revocation.

Troubleshooting

The two most common problems are straightforward.

Terminal Tab Is Greyed Out

If the Terminal tab is greyed out, the CLI on that machine is too old to support the browser terminal feature. Run the install command again to update the CLI. In most cases, the install script replaces the existing binary and you can reconnect immediately.

This machine already runs as device id in the background

This error appears when you try to run pinggy device login or pinggy device connect in the foreground while a background agent is already holding the connection to the dashboard. Stop it first:

pinggy device stop

After the background agent stops, you can run the foreground command again. If you want the device to stay connected, use pinggy device connect -b instead.

Device Does Not Come Back After Reboot

As I mentioned earlier, the background agent does not survive a reboot. If the machine restarts, run pinggy device connect -b again. To make this automatic, you can add a login item on macOS, a startup script on Windows, or a systemd user service on Linux. The Pinggy CLI does not install a system service by default, so you need to do this yourself if you want always on availability.

Shell Closes After Inactivity

Remember the 30 minute idle limit. If you step away from the browser terminal and the shell closes, any foreground process started inside it will also end. For long tasks, always use claude --bg or a process supervisor like tmux or screen. You can install tmux on the remote machine and run tmux inside the browser terminal. That gives you another layer of protection against shell timeouts.

Real-World Workflows

The flexibility of a browser terminal means you can do much more than run Claude Code. Here are a few workflows that work well.

1. Remote Development From a Thin Client

If you have a powerful desktop at home and a lightweight laptop on the road, you can leave the desktop connected with Pinggy and use its terminal from anywhere. Your IDE still runs locally, but the terminal controls the desktop. You can edit files through your IDE if you use a sync tool, or you can install a headless editor in a tmux session and use the browser terminal to do everything.

2. Server Maintenance

A cloud VM might only expose SSH through a bastion host. If you do not want to configure extra SSH keys, install Pinggy CLI on the VM and connect with a device token. From the browser, you can update packages, restart services, inspect logs, and run Claude Code to diagnose incidents. The outbound connection means you do not have to change security group rules.

3. Multiple Shells for a Complex Task

On the Pro plan, you can open three terminals on the same device at once. You might dedicate one shell to Claude Code, one to a local dev server, and one to Git or docker compose. Because each shell has its own tab, you can watch all three in the browser and switch between them quickly.

4. Headless Claude Code Tasks

You can start a Claude Code background session from the browser terminal and then detach. Close the browser tab. The session continues. Later, open a new shell, list the sessions, and attach to see the output. This gives you a very simple remote job queue for AI assisted coding tasks.

5. Pair Debugging

If you share a Pinggy account with a trusted teammate, both of you can sign in and open a shell on the same device. Since each shell is independent, two people can work on the same machine simultaneously. Be careful with concurrent Git operations in the same repository. You may end up with merge conflicts or index locks. Use separate worktrees or coordinate through Claude Code sessions.

Performance, Latency, and Practical Limits

A browser terminal is not as instant as a local terminal, but it is close. The Pinggy relay is optimized for terminal traffic, which is low bandwidth and high interactivity. Over a normal internet connection, keystroke latency is usually well under a second. The bigger bottleneck is often the responsiveness of the remote machine itself.

You can reduce latency by working near the machine's network region and by using a wired connection on the remote side. Wi-Fi with interference can cause jitter, especially if the remote machine is a laptop in sleep mode or on a weak signal. If you plan to run Claude Code for hours, make sure the machine does not go to sleep. In macOS, you can use caffeinate to prevent sleep while the terminal is active.

The dashboard terminal renders ANSI colors, box drawing characters, and Unicode output. Most modern browsers handle this well. If you notice text flicker or misaligned output, try a different browser or disable browser extensions that modify the DOM. The terminal client is also compatible with common terminal multiplexers like tmux and screen. If a shell ends because of inactivity, tmux can keep your session alive; the Pinggy shell can reconnect to the same tmux session in a new browser tab.

Edge Cases and Limitations

It is worth being explicit about what this setup does not do.

• The Pinggy agent must be running. If the machine is off, asleep, or the daemon is stopped, no terminal can connect.
• The free plan has one device and one concurrent terminal. Opening a second shell will fail until the first one is closed.
• A foreground process started in a normal dashboard shell dies when the shell ends. Background sessions started with claude --bg survive shell termination.
• The device token grants full access to a shell as the user who owns the token. Anyone with access to your Pinggy account has the same power.
• The terminal runs as the user who started the Pinggy agent, not as root. If you need root privileges, you can use sudo inside the terminal, assuming your user is allowed to.
• The browser terminal is not meant for very high bandwidth applications like streaming video or transferring large files. It is a terminal, not a general purpose tunnel. For file transfers, use a separate tunnel or an SCP session configured through Pinggy.
• The 30 minute idle limit applies to browser shells. Background CLI sessions are managed separately by Claude Code. If you use tmux, the tmux session persists even if the browser shell ends.

Frequently Asked Questions

Do I need a public IP address?

No. The machine only makes an outbound connection to the Pinggy relay. It works behind NAT, CGNAT, and most firewalls.

Can I run Claude Code without installing anything on the remote machine?

No. You need the Pinggy CLI installed on the machine you want to reach. The installation is a single command and does not require sudo.

Does the browser terminal support copy and paste?

Yes. Most browser terminals support clipboard operations through keyboard shortcuts or context menus. The exact behavior depends on your browser. On macOS, Cmd+C and Cmd+V generally work in the terminal's native menu or through the browser's clipboard permission prompts.

Is it safe to leave the Pinggy agent running all the time?

It is safe as long as your account is secured with a strong password and two factor authentication, and as long as the device token stays private. The agent itself only sends terminal keystrokes and output over an outbound TLS connection. It does not expose a generic port.

Can I use this with tools other than Claude Code?

Absolutely. The browser terminal is a full shell. You can run git, docker, vim, htop, node, python, Codex, or any other command. Claude Code is just one example, and a very useful one for AI driven development.

What happens if my browser crashes?

The shell on the remote machine stays alive for a while because the relay may not immediately know that the browser disconnected. When you reopen the dashboard and click the Terminal tab, the screen is redrawn to reflect the current state of the shell. If the shell hit the idle timeout, you will see a fresh shell instead.

Does claude --bg work through the browser terminal?

Yes. You can run claude --bg 'task' in any shell, including a browser shell. The background process is independent of the shell that launched it. As long as the Pinggy agent is running and the machine is on, the background session continues.

What is the difference between claude --bg and tmux?

claude --bg is specific to Claude Code and runs the agent in a separate supervised process. tmux is a general terminal multiplexer that keeps any interactive program alive across terminal disconnects. You can use both together: open a browser shell, start tmux, run claude inside tmux, and then detach from tmux. Even if the browser shell times out, the tmux session and Claude Code remain alive. The downside is that attaching to a tmux session is less convenient than claude attach for seeing recent output, because you have to reattach to the session.

Best Practices Checklist

• Use two factor authentication on your Pinggy account.
• Keep the device token out of logs and screenshots.
• Use pinggy device connect -b for long running machines.
• Create a startup job to reconnect after reboot.
• Use claude --bg for tasks longer than a few minutes.
• Check claude agents before starting another background session.
• Use tmux if you want a persistent interactive shell beyond Claude Code's background mode.
• Keep the remote machine awake with caffeinate on macOS or a power plan on Windows.
• Monitor the Overview tab to see if the machine is under heavy load.
• Rotate the device token when you stop using a machine.

Recap

The whole setup can be summarized in three commands. On the machine you want to reach, install and sign in:

curl -fsSL https://pinggy.io/install.sh | sh

Keep the device connected in the background:

pinggy device connect -b

From the browser terminal, start a Claude Code background task:

claude --bg '<your task>'

Then open the Pinggy Devices page, click the device, open the Terminal tab, and choose New shell. You now have a real terminal on that machine, running in a browser, ready for Claude Code or anything else.

The combination of an outbound only agent and a browser based terminal is a practical answer to a very common developer problem: your best coding environment is stuck on a machine you are not in front of. Pinggy Devices solves that without requiring you to open ports, maintain a VPN, or leave an SSH server exposed. It is simple, close to the metal, and works with the AI coding tools you already use.

Reference

• Run Claude Code Remotely from Any Browser with Pinggy