PinchTab
Browser control for AI agents
Small Go binary • HTTP API • Token-efficient
What is PinchTab?
PinchTab is a standalone HTTP server that gives AI agents direct control over Chrome.
For day-to-day local use, the server is typically installed as a user-level daemon, allowing agent tools to reuse the same browser control plane running in the background.
curl -fsSL https://pinchtab.com/install.sh | bash
# or
pinchtab daemon install
This installs the control-plane server and starts a default headless Chrome instance, ready to accept requests from agents or manual API calls.
PinchTab is designed first for local, single-user control on a machine you manage. Remote and distributed layouts are supported, but they are advanced operator-managed deployments. If you bind beyond loopback, publish ports, or attach remote bridges, you are responsible for tokens, network boundaries, TLS or reverse proxying, and which endpoint families you expose.
If you run PinchTab on a different machine, do it only when you understand the security model. Keep it on a private or otherwise closed network, avoid exposing it directly to the public internet, and keep high-risk endpoint families disabled unless you explicitly need them. If you do enable them, lock them down so only the systems that need them can reach them.
[!WARNING]
The dashboard, HTTP API, MCP server, and remote CLI integrations are privileged operator control surfaces. They are not designed for untrusted users, multi-tenant exposure, or direct public-internet access. If you are unsure how to secure a non-local deployment, review docs/guides/security.md and use the private security contact path in SECURITY.md before exposing the service.
If you prefer not to run a daemon, or if you're on Windows, you can instead run:
pinchtab server — runs the control-plane server directly
pinchtab bridge — runs a single browser instance as a lightweight runtime
PinchTab also provides a CLI with an interactive entry point for local setup and common tasks:
pinchtab
Security
PinchTab defaults to a local-first security posture:
server.bind = 127.0.0.1- dashboard session cookies are
Secure only when the dashboard is actually served over HTTPS
- sensitive endpoint families are disabled by default
attach is disabled by default- IDPI is enabled with a local-only website allowlist
If you intentionally access the dashboard over plain HTTP on a non-loopback
address, PinchTab now warns in the UI that the session is running without
transport encryption. Prefer HTTPS or localhost when possible. If you force
server.cookieSecure = true, dashboard login requires HTTPS and will fail
explicitly on plain HTTP instead of looping silently.
[!CAUTION]
By default, IDPI restricts browsing to locally hosted websites only.
This prevents agents from navigating the public internet until you explicitly allow it.
The restriction exists to make the security implications of browser automation clear before enabling wider access.
Expanding browsing to non-local or non-trusted websites is a security-reducing choice. Hostile pages can still increase browser attack surface and interact badly with enabled automation features even when PinchTab's content defenses are on.
See the full guide: docs/guides/security.md
Remote, container, and distributed setups are possible, but PinchTab is not positioned as a turnkey internet-facing browser service. Treat any non-local deployment as an advanced setup that you must secure explicitly.
What can you use it for
Headless navigation
With the daemon installed and an agent skill configured, an agent can execute tasks like:
"What are the main news about aliens on news.com?"
