Are you tired of being tied to your desk just to use your AI coding agent? Imagine you are on a train, at a coffee shop, or using a tablet at home, and you need to check on a long-running refactor, start a new session, or continue where you left off. With Pinggy and OpenCode, you can access a full terminal on your remote machine from any browser, without setting up an SSH server, opening a port, or assigning a public IP address. This guide walks through everything you need to know, from initial setup to advanced session management, security best practices, and troubleshooting.
Why a Browser Terminal?
Developers often need to reach a powerful workstation or server from a lightweight device. Traditional solutions like SSH require the target machine to expose a port and have a public IP, which is not always possible behind NAT, CGNAT, or strict corporate firewalls. You could use a VPN, but that adds complexity and can be blocked by network administrators. Pinggy solves this problem by having your machine make a single outbound connection to the Pinggy dashboard. Your browser talks to the dashboard, and the dashboard relays keystrokes through that connection to a shell on your machine. This is a form of remote terminal that works regardless of your network topology.
The beauty of this approach is that there is no inbound connection. The Pinggy CLI, running as a background agent, keeps a persistent WebSocket connection to the Pinggy servers. When you open a terminal tab in the Pinggy dashboard, the browser sends input events to the server, which forwards them over the existing connection to a pseudo-terminal on your machine. The output is streamed back in real time. The result is a responsive terminal in your browser that feels local, even across continents.
For developers working with AI coding agents, this is particularly useful. AI tools like OpenCode often run long tasks, generate large files, and need to execute tests. You do not want to keep a laptop lid open and a terminal session active just to watch a progress bar. With a browser terminal, you can start a task, close the tab, and check back later. The process continues because it is running on your remote machine, not in the browser.
How Pinggy Devices Work
Pinggy Devices is a feature that arrived in Pinggy CLI v0.6.2 on November 2, 2026. The CLI runs on your machine as an agent and maintains one outbound connection to the dashboard. That connection is authenticated with a device token, which is bound to your Pinggy account. When you open a browser terminal, the Pinggy front end communicates with the agent through a relay that is similar to a WebSocket bridge. The agent accepts the connection and spawns a shell process (usually /bin/bash or /bin/zsh) on the host operating system.
The system is designed to work behind NAT and CGNAT because the agent only initiates outbound connections. There is no need to configure port forwarding on your router. The agent periodically sends keepalive pings to detect dropped connections. If your internet goes offline and comes back, the agent should reconnect automatically, unless the network change is too severe or the machine goes to sleep.
Since v0.6.4, released on November 5, the agent runs in the background by default. This is a significant improvement because it means you can close the terminal window that launched the agent, and the device remains online. The background agent is managed as a user-level daemon, so it does not require administrator privileges. It stores its configuration in your user configuration directory, typically ~/.config/pinggy/ on Linux and macOS, or %USERPROFILE%\.config\pinggy\ on Windows.
The device token is stored in device.json within that directory. Permissions are set to read-only for the current user, preventing other local accounts from stealing the token. The agent never logs the actual keystrokes or terminal content. Instead, it forwards the rendered output to the dashboard, which means the dashboard cannot inject commands or extract data from the terminal. It is a pure remote display protocol, similar to how a VNC client works but optimized for text.
Understanding OpenCode's Client-Server Model
OpenCode 2 is not just a single binary that runs in the foreground. It is split into a client and a server. The opencode command you type is a terminal client that connects to a background server. This server, which starts automatically when you first run OpenCode, is responsible for managing sessions, permissions, and tool execution. It listens on 127.0.0.1:49374 on macOS and Linux. This design is what makes OpenCode an ideal companion for a browser terminal.
When you open a shell through Pinggy and run opencode, the client attaches to the existing background server. If your browser tab crashes, the shell might be terminated, but the server stays alive. Your active session continues running in the background. You can later open a new shell, resume the session, and see exactly where you left off. This separation is powerful, especially for long-running AI code generation tasks that might take several minutes. You can even close the browser entirely and come back hours later to find the task completed.
The background server also centralizes permissions. When OpenCode wants to run a command or modify a file, it asks the user through the TUI. But when you are running in a browser terminal, you interact with the TUI as usual. The server enforces the same permission rules even if the client disconnects and reconnects. This means a long-running task will not accidentally execute a command that you did not approve. You can also revoke permissions through the TUI before disconnecting.
OpenCode is MIT-licensed and has gathered an impressive 225,629 GitHub stars as of November 9, 2026. The project has rapidly evolved, and v2 introduced a more robust plugin system and a new TUI. The background server model was added specifically to support scenarios like this, where the client and server can be separated across time and space.
In my test run on November 9, I used an Apple Silicon MacBook with Pinggy CLI 0.6.4 and OpenCode 2.2.6, released on November 6. I added the machine using the dashboard's token command. Most screenshots in this guide come from that run, and a few were taken on November 10 in the dashboard's dark theme. Two images come from our Claude Code guide. All tokens, emails, hostnames, and usernames are placeholder values. Plan numbers and limits were checked against the Pinggy Devices documentation.
Prerequisites
Before we dive into the setup, let us make sure you have everything needed. You need a machine where your code lives. This could be a MacBook, a Linux server, a Windows PC, or even a Raspberry Pi. The Pinggy CLI supports all of these platforms. You also need a modern web browser, such as Chrome, Firefox, Safari, or Edge. Finally, you need an OpenCode installation. The setup process takes about five minutes, and most of it is just running two install scripts and signing in with your email.
Network requirements are minimal. The machine must be able to reach the internet and maintain an outbound connection to the Pinggy servers. The browser, likewise, needs internet access and a WebSocket-capable connection. There is no need for a static IP, router configuration, or VPN. This is one of the biggest advantages of using Pinggy instead of traditional remote access tools.
You should also have a Pinggy account, which you can create for free during the sign-in process. If you plan to use OpenCode with custom AI providers, make sure you have your API keys ready. For local models, you need a tool like Ollama installed on the machine.
Step 1: Install Pinggy CLI and Sign In
The first step is to install the Pinggy CLI on the machine you want to reach from the browser. This is a simple one-liner. On macOS and Linux, open a terminal and run:
curl -fsSL https://pinggy.io/install.sh | sh
On Windows, open PowerShell and run:
irm https://pinggy.io/install.ps1 | iex
The install script does not require sudo. It downloads the CLI, places it in your user directory, and then runs the login flow. You will be prompted to enter your email address, after which Pinggy sends a six-digit verification code. Type that code into the terminal. Alternatively, you can click the "Approve sign in" button in the email, but only if the page displays the same device code that your terminal printed. This prevents phishing and ensures the request is legitimate.
A quick note on typo awareness: some users recieve the code in their spam folder, so check there if you do not see it within a minute. The code expires after a short window, and you can request a new one if needed.
If you do not have a Pinggy account, the email address you provide automatically creates a free account. The machine is then added to your account with a device name that matches its hostname. You can change this name later from the dashboard. The device entry shows the hostname, OS, CPU, and memory, which helps you identify the machine when you have multiple devices.
After successful sign-in, the CLI prints a link and a QR code to the device's page in the dashboard. Starting with CLI version 0.6.4, the agent runs in the background by default. This means the CLI process exits but the agent continues running, maintaining the outbound connection. You can close the terminal window and the device stays online. After a reboot, the agent does not start automatically. You will need to run pinggy device connect again. Since your token is saved, it will not ask for credentials again. If you have an older CLI version, the agent might run in the foreground. Simply run the install script again to update.
If you already have a Pinggy account and want to add a new machine, go to the Devices page in the dashboard and click "Add device." Give the machine a name. The dashboard will show a command that includes a unique device token. You can run this command directly on the machine. This method does not require email or a verification code, which makes it perfect for servers or machines that you only reach through a script. The exact command looks like this, with a placeholder token:
pinggy device connect --token YOUR_DEVICE_TOKEN
On a machine that already has the CLI installed, this command will connect immediately. It might also check for updates and inform you if a newer version is available. If the machine was already registered as a device on another account, the CLI will say so and leave the old device in the other dashboard, offline. You can remove the old device from the previous account if you have access to it.
One common question is whether you can run the agent alongside another Pinggy tunnel. The answer is yes, they are independent features. You can have an existing localhost tunnel active while the device agent runs in the background. The device agent uses a different authentication flow and does not interfere with your tunnel configuration.
Step 2: Install OpenCode on the Machine
Now that your device is connected to Pinggy, you need to install OpenCode. You have two options: run the install command in a local terminal on the machine, or wait until you have opened a browser shell in Step 3 and run it there. The latter is particularly useful if you want to set up a new machine completely from your tablet or phone.
The easiest installation method is the official installer. Run this in your terminal:
curl -fsSL https://opencode.ai/v2/install | bash
This installs the OpenCode 2 binary. If you already have OpenCode 1 installed, the v2 installer will replace the old binary. That is exactly what happened on my MacBook, where version 1.3.10 was replaced by OpenCode 2.2.6. If you installed OpenCode 1 through a package manager, it is recommended to uninstall it first to avoid conflicts. The v2 installer preserves your existing configuration, including your default model. However, v1 plugins do not run in OpenCode 2, so you may need to find replacements.
Alternative installation methods include:
npm install -g @opencode/cli
and, on macOS with Homebrew, you can run:
brew install anomalyco/tap/opencode-v2
Both methods work well. The npm package is particularly convenient if you already have Node.js installed, but the standalone installer is more self-contained. Windows package managers are not yet supported. Instead, the OpenCode documentation provides a standalone Windows build that you can download and run. OpenCode 1 also works in the browser terminal. If you still have a v1 installation and want to keep it, that is fine. In fact, here is what OpenCode 1.3.10 looked like in the Pinggy terminal tab, running with a local Ollama model:
However, the rest of this guide focuses on OpenCode 2 because its background server architecture provides seamless session persistence. For the best remote experience, I highly recommend upgrading to v2. If you need to migrate, copy any custom configuration from ~/.config/opencode/ to the new location that v2 uses. The installer usually handles this, but it is good to verify.
One of the first questions people ask is whether they need an account to use OpenCode. You do not. The free tier includes access to several free models, such as Big Pickle, DeepSeek V4.1 Flash Free, and GLM-5.3-Flash Free. You can start coding immediately with these models. That said, OpenCode stores your data when you use free models. If you are working with proprietary or sensitive code, connect your own provider. Use the /connect command inside the OpenCode TUI, or run opencode auth login from the shell. API keys can be pasted easily into the browser terminal. For providers that use OAuth or browser-based sign-in, it is a good idea to authenticate while you are still at the machine, before you start relying on remote sessions.
Step 3: Open the Browser Terminal and Run OpenCode
With both Pinggy and OpenCode installed, it is time to open the terminal in your browser. Go to the Pinggy Devices page and click on your device's name. The Overview tab shows whether the device is online, along with its hostname, operating system, CPU, and memory. The screenshot below shows the dark theme of the dashboard, which is easy on the eyes for late-night coding sessions.
Click the Terminal tab and then click "New shell." A new terminal tab will open, connected directly to a shell on your machine. This shell runs as the same user that ran the pinggy command. That means it has access to your user's files, git configuration, and saved provider logins. This is critical because OpenCode needs to see your SSH keys, your project directories, and your API tokens.
Once the shell is up, navigate to your project and start OpenCode:
cd ~/code/storefront # your own project folder
opencode
The first time you run OpenCode 2.2.6 after an update, it may show a "What's new" dialog. You can close it by pressing Esc. In my case, OpenCode opened on the local Ollama model from my existing configuration. I wanted to use Big Pickle, so I pressed Ctrl+X, then M, typed "big pickle" and pressed Enter. The Ctrl+X key sequence went through the browser terminal without any issues.
Then I asked OpenCode to write a test file, specifically "Write cart.test.js with three node:test tests for cart.js." Big Pickle wrote the file and ran the tests in 11.3 seconds. The latency was barely noticeable, even though the browser tab was communicating through the Pinggy relay. The entire experience felt just like a local terminal.
Once you are inside OpenCode, the usual keybinding s work. Here are a few commands to help you get started:
- /models to switch models. This opens an interactive picker where you can browse all available models, including local ones.
- /connect to add a provider. You can enter an API key or choose an OAuth provider.
- ! at the start of an empty prompt to run a shell command directly. This is handy for quick file checks.
- Ctrl+P to open the command palette. From there, you can run actions like session list, continue, or toggle permissions.
You can also use Ctrl+X and then M to select a model, as I did. The browser terminal supports all standard terminal key combinations, including Ctrl+C to interrupt, Ctrl+L to clear, and Ctrl+R to search shell history.
One tip: if you are using an iPad or tablet, make sure you have a keyboard connected. The browser terminal works with touch, but the AI coding TUI is much easier with a physical keyboard.
Step 4: Resume Sessions Later
One of the best parts of this setup is that closing the browser tab does not kill your shell. The Terminal tab in the Pinggy dashboard lists all shells that are still running on the device. Each shell has its own tab, and the list shows the program currently running in each. Clicking on a shell reopens it with the screen redrawn. This is incredibly useful when you accidentally close a tab or need to switch devices.
There is, however, a timeout limit. A dashboard shell will end after 30 minutes with no activity, and it will definitely end after 8 hours, regardless of activity. When the shell ends, the OpenCode client running inside it also ends. But because OpenCode's background server holds the session, you can simply open a new shell and resume.
To test this, I deliberately hung up the shell from the machine's side, which is exactly what a timeout does. The OpenCode client exited, but the session was still alive. In a new shell, I ran:
cd ~/code/storefront # sessions belong to a project folder
opencode session list # list sessions; it opens in a pager, press q to leave
opencode -c # continue the last session
The output of session list looked like this:
ses_e40039520ffev5jRWwjsz0uEAl Three node:test tests for cart.js 11/9/2026, 4:36:04 PM
Then opencode -c opened the session exactly where I had left off. You can also open a specific session by ID with opencode -s . Inside the TUI, /sessions (or Ctrl+X, then L) lists all sessions as well.
What about work in progress? I ran an experiment. In a local terminal, I killed the opencode client eight seconds into a task, using the same hang-up signal that a closing shell would send. The background server kept running, and the file that OpenCode was writing appeared about 16 seconds later, with no client attached. This means you can start a long task, close the browser, go for a walk, and come back later to see the result. As long as the machine stays awake and connected, the task will complete.
There is a subtle edge case. If the shell times out due to inactivity, the OpenCode client receives a SIGHUP. The client might not have time to flush its output buffer, but the background server handles all file writes and tool executions. Therefore, you will not lose any generated files. The only thing you lose is the in-memory UI state, which includes the scrollback and any unsubmitted prompt. The session history is preserved on disk.
Another useful feature is the ability to run multiple shells simultaneously. With the Pro plan, you can have up to three shells per device. For example, you can run OpenCode in one shell, a dev server in another, and tail logs in a third. Each shell is an independent process group, so commands do not interfere with each other.
Advanced Session Management
OpenCode's session system is more powerful than it first appears. Sessions are tied to a project folder. If you run opencode in a subdirectory, it will still find sessions from the parent folder. You can use session IDs to programmatically continue a session, which is useful for scripts and automation. For example, you can write a shell alias:
alias oc='cd ~/code/storefront && opencode -c'
This makes it quick to resume your last session from any shell. You can also archive old sessions to keep the list clean. The /sessions command has an archive option.
One recurring issue is that sessions can become orphaned if the server crashes. The server stores session metadata and file changes incrementally, so you rarely lose data. If you ever need to kill a hung session, you can restart the OpenCode server with opencode service restart. This will not delete sessions.
Setting Up Local Models with Ollama
One of the best ways to get low-latency AI assistance in a remote terminal is to run a local model. Ollama is a popular tool for running open-source language models on your own hardware. To install Ollama on the remote machine, use the install script:
curl -fsSL https://ollama.com/install.sh | sh
Once installed, pull a model such as qwen2.5-coder:14b or llama3.1:8b:
ollama pull qwen2.5-coder:14b
Then start the Ollama server. It runs as a background service by default. In OpenCode, you can select Ollama as the provider and pick the model you pulled. The interaction happens over the localhost server, so even the browser terminal will see negligible latency. This setup is particularly useful when you are using a remote machine with a powerful GPU. You can leave the GPU at home and use a thin client elsewhere. However, make sure the model fits in memory. The qwen2.5-coder:14b model needs about 10 GB of RAM. If the machine has 16 GB or more, you are fine.
Ollama also supports multiple models and can switch on demand. You can use /models inside OpenCode to list them. The first request will load the model into memory, which might take a few seconds. Subsequent requests are fast. If you notice slow performance, check the CPU and memory usage with htop.
Running the Pinggy Agent as a Service
If you want the Pinggy device to be always available, especially on a server, you should run the agent as a service. On Linux, you can create a systemd user unit. First, make sure the agent is not already running. Then create the unit file:
mkdir -p ~/.config/systemd/user
cat > ~/.config/systemd/user/pinggy-device.service <<EOF
[Unit]
Description=Pinggy Device Agent
After=network-online.target
Wants=network-online.target
[Service]
ExecStart=%h/.pinggy/pinggy device connect --foreground
Restart=on-failure
RestartSec=5
[Install]
WantedBy=default.target
EOF
Then enable and start it:
systemctl --user daemon-reload
systemctl --user enable --now pinggy-device.service
Make sure lingering is enabled for your user so the service starts at boot without you logging in:
loginctl enable-linger $(whoami)
This setup ensures that the Pinggy agent is always running and reconnects automatically after a crash or reboot. On macOS, you can do something similar with a launchd LaunchAgent. On Windows, use Task Scheduler.
OpenCode Configuration Tips
OpenCode stores its configuration in ~/.config/opencode/. You can edit the opencode.json file to set default models, theme, and permission policies. For example, to set a default provider and model:
{
"model": "big-pickle",
"provider": "opencode"
}
You can also define custom prompts and agent behaviors in a prompts/ directory. This is helpful when you have recurring tasks, such as "create a commit message" or "write unit tests." The configuration files are plain text, so you can version them with git. If you are using OpenCode through a browser terminal, you might want to increase the terminal font size for readability. You can do that in the TUI settings.
Permission policies are particularly important in a remote environment. You can configure OpenCode to ask for permission only once per session, or to auto-approve certain commands like npm test and git status. This reduces the number of interruptions while you are away from the keyboard.
OpenCode's Own Remote Access, and Why a Shell
OpenCode has its own remote access feature. The command opencode pair prints a one-time link and a QR code to its web UI. This link is valid for 5 minutes. With opencode pair --remote, you can pair from anywhere through an OpenTunnel address. This option exposes your OpenCode server to the internet. It is end-to-end encrypted and protected by a password, and OpenCode asks for confirmation before turning it on. On a phone, the OpenCode web UI or mobile app is arguably nicer than a TUI in a browser tab. If you only need to interact with OpenCode, this might be enough.
But a Pinggy shell is a whole terminal, not just an OpenCode session. You can restart the OpenCode service, run git pull, restart a dev server, or even run Claude Code in a seperate tab. Nothing about the OpenCode server is exposed to the internet. The shell is just a terminal. This is especially valuable if you want to inspect system logs, edit configuration files, or perform maintenance tasks in the same environment. Our Claude Code guide covers the same setup for Claude Code, and you can run both tools side by side. The screenshot below shows Claude Code 2.1.318 running in the same Pinggy terminal tab, from the Claude Code guide.
Having a full terminal also means you can use tools like htop, vim, tmux, or any other command-line utility. You can start a local web server and test it by opening another tunnel. The possibilities are endless. If you are a sysadmin, you can even use the browser terminal to manage nginx configuraton files, restart services, and read logs, all without leaving the browser.
Free vs Pro
The browser terminal is available on every Pinggy plan, including the free one. The free plan includes one device and one concurrent shell. That is enough for a single developer with one machine. The Pro plan costs $2.50 per month if billed annually, or $3 per month if billed monthly, as of November 3, 2026. It raises the limits to 25 devices, three concurrent shells per device, and ten open shells per seat. Three shells is a comfortable number for most workflows: one for OpenCode, one for the dev server, and one for git operations. For a more detailed breakdown, check the Pinggy pricing page.
If you are collaborating with a small team, each seat gets its own device and shell limits. You can also share devices across the team if you all sign in to the same account, though that raises security concerns that we will address shortly. The Pro plan also includes priority support and higher bandwidth limits. If you are using the browser terminal for heavy output, such as test suites that print thousands of lines, you will appreciate the increased throughput.
One thing to note is that the free plan's single shell can be a limitation if you want to run OpenCode and a dev server concurrently. You can work around this by using tmux inside the single shell, but the Pro plan's three shells are more ergonomic. You can always upgrade or downgrade at any time, and the pricing is transparent.
Security Best Practices
When you give remote access to your development environment, security becomes paramount. The device token is stored in a file called device.json under ~/.config/pinggy/. The file is readable only by your user account. Pinggy documents that the agent never logs what you type. The Activity tab in the dashboard lists device events, including source IP addresses, so you can monitor for suspicious access.
Here is the important part: anyone who is signed in to your Pinggy account can open a shell on your devices. And since the shell runs as your user, that person has access to your source code, your provider keys, and your entire user environment. Therefore, you must enable two-factor authentication (2FA) on your Pinggy account immediately. Do not share screenshots of the dashboard's connect commands, because they contain the device token. Treat those tokens like SSH private keys.
If you need to revoke access, you have two options. You can delete the device from the dashboard, which severs the connection and prevents it from connecting again with the old token. Or you can rotate the device's token from the dashboard. The local pinggy device remove command only forgets the token on your machine; it does not revoke it remotely. Make sure you understand the difference.
For an extra layer of security, consider using a dedicated service account for background agents, or limit the permissions of the user that runs the Pinggy CLI. On Linux, you can use systemd to run the agent under a separate user with limited access. On macOS, you might want to use the built-in firewall and app sandboxing. If you are working with highly sensitive code, you can also combine Pinggy with your own authentication proxy, but that is probably overkill for most developers.
Another good practice is to set a short screen lock timeout on the machine that runs the agent. If an attacker gains physical access to the machine, they could read the device token and use it to access your Pinggy account. Full disk encryption is also recommended. The agent itself does not store any plaintext credentials beyond the device token and your shell environment variables.
Troubleshooting
Even with a smooth setup, you might encounter issues. Here are some common problems and how to resolve them.
Terminal tab is greyed out
The most likely cause is that the Pinggy CLI on your machine is too old to support the browser terminal. The terminal tab becomes available in CLI version 0.6.2. If you have an older version, run the install command again to update the CLI. The command is the same one you used for installation.
This machine already runs as device in the background
If you try to run pinggy device login or pinggy device connect --foreground while a background agent is already running, you will see this message. Stop the background agent first with pinggy device stop. Then you can run the foreground command. This is a common mistake when you are testing multiple authentication methods. The background agent already holds the connection, so the foreground command cannot establish a second one.
opencode -c shows an error about "ses"
When you run opencode -c in a folder that has no OpenCode sessions, you might see an error like Expected a string starting with "ses" followed by an empty session. This happens because you are in the wrong directory. In a fresh browser shell, you start in your home directory, not in your project folder. You need to cd into the project folder first. Alternatively, open a session by its ID with opencode -s .
OpenCode can't reach its server
If the OpenCode client cannot connect to the background server, you will see a connection error. Run opencode service status to check the server's state. If it is stuck, use opencode service restart. This usually resolves the issue. If the server is not running at all, starting a new opencode command should launch it automatically. Sometimes the server's port, 127.0.0.1:49374, is occupied by a different process. You can check with lsof or netstat.
Input lag or slow key response
The browser terminal should feel snappy, but if you notice latency, check your network connection. The Pinggy relay is optimized for low-latency, but a poor internet connection on either end can cause delays. You can also try using a wired connection on the machine side, or switching browsers. Some browser extensions might interfere with WebSocket connections, so try disabling them temporarily.
Clipboard issues
Copying and pasting large amounts of text between your local machine and the browser terminal can sometimes be flaky. Use the terminal's own copy and paste shortcuts. In most browser terminals, Ctrl+Shift+C and Ctrl+Shift+V work. For very large pastes, consider echoing the text into a file first. If you are using a Mac, Cmd+C and Cmd+V may work instead.
The machine goes offline unexpectedly
If the device shows as offline in the dashboard, the agent might have crashed or the network connection was lost. Check if the machine is awake and has internet access. You can restart the agent by running pinggy device connect again. If the machine rebooted, the agent will not start automatically, so you need to launch it manually.
Permission denied when running opencode
The shell user may not have execute permission for the OpenCode binary, or the binary may be in a directory that is not in the PATH for the shell that Pinggy starts. Use an absolute path like ~/.opencode/bin/opencode or add the directory to your shell profile. You can also reinstall OpenCode with the official installer, which handles PATH configuration.
"Device code" mismatch
During login, the email shows a device code that should match the code displayed in your terminal. If they do not match, do not approve the access. This is a safeguard against session hijacking. The code changes on every attempt.
Performance and Reliability
The Pinggy agent maintains a single outbound connection, which is remarkably stable. In my tests, it survived network changes and sleeps on the laptop, though a reboot will obviously disconnect. The connection uses TLS, so all data is encrypted in transit. The relay servers are distributed, but the latency depends on the physical distance between your browser, the Pinggy relay, and your target machine. For most development tasks, the latency is negligible.
To get the best performance, close unnecessary browser tabs and keep your machine awake. On macOS, use caffeinate if you want to prevent sleep during a long task. On Linux, you can adjust the power settings. You might also want to use a tool like tmux inside the shell to create persistent sessions that survive shell disconnects. Although OpenCode's server provides session persistence, tmux gives you a more general solution for any process.
Network quality matters. If you are on a cellular connection, you may experience occasional jitter. The terminal protocol is text-based, so the bandwidth usage is low, but packet loss can cause lag. Try to maintain a stable Wi-Fi or Ethernet connection on both sides. If the machine is in a region with high latency, you can still use OpenCode comfortably, but the initial render of a large scrollback might take a second or two.
Another performance factor is the model you choose. Local models running on the machine, like those served by Ollama, do not depend on internet speed and can be very fast. Cloud models, on the other hand, require streaming iterations over the internet, and the browser terminal adds a tiny overhead. In practice, the overhead is less than 10%, which is not noticeable.
Real-World Use Cases
The combination of Pinggy and OpenCode is perfect for several scenarios.
- Road warrior developer: You are working from a tablet or a borrowed laptop. You connect to your powerful desktop at home and run OpenCode exactly as if you were sitting in front of it.
- Server maintenance and AI assistance: You have a headless server that hosts your application. You can run OpenCode on the server to refactor code, inspect logs, and run tests, all from a browser.
- Temporary workstations: You are at a client site and need to access a development environment behind their strict firewall. The client machine initiates the outbound connection, so no firewall changes are required.
- Pair programming across locations: Two developers can sign in to the same Pinggy account and open separate shells on the same device. They can even run tmux and attach to the same session for collaborative debugging.
- Cost efficiency: Instead of carrying a heavy laptop around, you can use a thin client or a Chromebook and offload all computation to your main machine.
Let me give you a concrete example. I often leave my MacBook Pro at home, plugged into a dock with multiple monitors. When I am traveling, I use an iPad Pro with a keyboard. I open the Pinggy dashboard, start a terminal shell, and run opencode. The iPad is now a full development environment. I can also use the local Ollama model to avoid sending code to third-party servers, which is useful for confidential projects.
For teams, the ability to access shared servers remotely from a browser can reduce the need for VPNs. A QA engineer can open a shell on the staging server and run OpenCode to debug an issue, while a backend developer is simultaneously connected to the same device through another shell. This is much simpler than coordinating SSH keys and jump hosts.
Comparing with Alternative Remote Dev Tools
There are other ways to access a remote terminal, such as SSH with port forwarding, VS Code Remote, or tools like ngrok. SSH is secure and reliable, but it requires the target machine to be reachable, which is often not the case behind CGNAT. VS Code Remote is excellent for editor integrations, but it is heavier and still requires a tunnel for clients. Pinggy provides a lightweight, browser-based terminal that works everywhere and does not require agent installation on the client, only on the host. It does not offer a full IDE, but for a terminal-based AI coding tool like OpenCode, that is all you need.
OpenTunnel, mentioned earlier, is great for exposing a specific service to the internet, but it exposes the service itself. With Pinggy, you are not exposing any service; you are exposing a login-protected terminal endpoint. This is a fundamental difference.
We should also mention that Pinggy supports SSH access through a different feature. If you prefer a native SSH terminal, you can configure Pinggy to provide an SSH host. However, for browser-based access, the Devices terminal is the simplest.
Common Pitfalls and How to Avoid Them
Even experienced developers can stumble when setting up a remote terminal. Below are some mistakes I have seen, and how to avoid them.
- Forgetting to update the CLI: The browser terminal feature is relatively new. Always use the latest Pinggy CLI to get the most up-to-date features and security fixes. Re-run the install script periodically.
- Using the wrong shell: The dashboard terminal spawns the user's default shell. If you have customized your shell with a startup script that expects a TTY or specific environment variables, make sure the script does not hang. Some shell profiles display messages that can confuse the terminal emulator. Keep your profile scripts robust.
- Assuming the background agent starts after reboot: It does not. You must add it to your startup items if you want it to persist. On macOS, you can use launchd. On Windows, use Task Scheduler. On Linux, use systemd user units.
- Running heavy AI tasks on a weak machine: The browser terminal is just a front end. The actual AI processing happens on the remote machine. Make sure that machine has enough CPU, memory, and GPU resources. Otherwise, tasks will be slow even with a fast connection.
- Not securing your provider API keys: If you connect a provider and save the API key in OpenCode's config, anyone with access to your Pinggy shell can use it. Limit the damages by using short-lived keys or a dedicated billing account.
Frequently Asked Questions
Do I need to keep the Pinggy CLI running in the foreground?
No, starting from version 0.6.4, the agent runs in the background by default. It will persist until the machine reboots. If you want to stop it, use Pinggy device stop.
Can I use the free plan for this?
Yes, the free plan includes one device and one shell. That is sufficient to run OpenCode and do meaningful work. If you need multiple shells or more devices, consider upgrading to Pro.
Does OpenCode 2 work with all of my existing plugins?
No, v1 plugins are not compatible with v2. You will need to migrate them or find alternatives. The core functionality, including model selection and tool execution, is built-in.
Can I run OpenCode on a Windows machine?
Yes, OpenCode has a standalone Windows build. The Pinggy CLI also works on Windows through PowerShell. The browser terminal works exactly the same way. The background server listens on a local port, and the client connects as usual.
Is it safe to leave the browser terminal tab open?
It is as safe as any terminal session. However, you should always lock your screen when away from your device, and enable 2FA on your Pinggy account. The terminal shell has full access to your user account, so treat it with the same caution as a local terminal.
What if my machine goes to sleep?
If the machine goes to sleep, the Pinggy agent will disconnect. When it wakes up, it may reconnect automatically, depending on your settings. OpenCode's server should resume, but if the machine was asleep for a long time, you might need to restart the agent.
Can I use multiple Pinggy tunnels and the device agent at the same time?
Yes, the features are independent. The device agent does not interfere with localhost tunnels. You can have one terminal for OpenCode and another tunnel for your web app simultaneously.
Does the browser terminal support tmux and other GUI tools?
It supports terminal-based tools, including tmux, vim, htop, and most command-line applications. It does not render graphical X11 applications, but there is no need for that in this context.
Recap
Let us summarize the entire setup in a few commands. First, install Pinggy and sign in:
curl -fsSL https://pinggy.io/install.sh | sh
Then install OpenCode 2:
curl -fsSL https://opencode.ai/v2/install | bash
Open the Pinggy Devices page, click your device, go to the Terminal tab, and start a new shell. Then run:
cd ~/code/storefront
opencode
To resume a previous session later, use:
opencode -c
That is all there is to it. You now have a full OpenCode environment that follows you anywhere, without any port forwarding, SSH daemons, or public IP addresses. The only requirement is that your development machine stays powered on and connected to the internet.
We hope this guide helps you become more productive and flexible. Whether you are a solo developer, a remote worker, or a team lead, the ability to run AI coding tools from any browser is a game changer. If you run into problems, refer to the official documentation and leave a comment below.
Top comments (0)