# PinchTab: a Go HTTP control plane for Chrome, built for AI agents

> PinchTab is a standalone Go server that drives Chrome over an HTTP API and an MCP server, with a local-first security posture that blocks public browsing by default. It suits single-user agent workflows, not multi-tenant browser farms.

**pinchtab/pinchtab** — High-performance browser automation bridge and multi-instance orchestrator with advanced stealth injection and real-time dashboard.

- Repository: https://github.com/pinchtab/pinchtab
- Stars: 10,321 · Forks: 779
- Language: Go
- License: MIT
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/pinchtab-pinchtab

## The token bill that PinchTab is trying to cut

An agent that reads a raw page spends most of its context on markup it will never act on. PinchTab's answer is to put a browser behind a small HTTP server and expose browser tools that return structured content instead of raw HTML or images. The README frames the payoff directly: agents can navigate pages, extract structured content and interact with the DOM "without wasting tokens on raw HTML or images". The target user is someone wiring an agent to a real browser, not someone writing a Selenium suite. The README's own examples are agent-shaped: asking for the main news about aliens on a news site, or telling an agent to log into a work profile and download the weekly report. PinchTab is written in Go, ships under MIT, and the go.mod pins Go 1.26.0, so it is a compiled binary rather than a Node or Python runtime you install into a virtualenv.

## Server-first architecture: daemon, bridge, and per-instance Chrome

The process model is stated plainly in the README: PinchTab is server-first. You install the daemon or run pinchtab server for the full control plane, and the server manages profiles and browser instances. A second mode, pinchtab bridge, runs a single browser instance as a lightweight runtime, which is the piece you would place next to a Chrome that lives somewhere else. The control plane speaks HTTP, and the README lists the dashboard, HTTP API, MCP server and remote CLI integrations as the surfaces it exposes. MCP matters here because go.mod depends on github.com/mark3labs/mcp-go, so the agent-facing protocol is a first-class part of the build rather than a wrapper script. Chrome control itself goes through chromedp and the Chrome DevTools Protocol, with gost-dom/browser and the pinchtab semantic, seaportal and idpishield modules in the dependency list. For multi-instance work the README says PinchTab can manage multiple Chrome instances, headless or headed, across containers or remote machines, and that you can connect to several PinchTab servers or attach to Chrome running in remote debug mode. Note the asymmetry: attach is disabled by default, so the distributed story is something you turn on deliberately.

## Installing PinchTab and running a first audit

The README gives two install paths. The install script fetches and runs the installer, and the daemon subcommand installs the server as a user-level daemon so agent tools can reuse one background browser control plane.

```bash
curl -fsSL https://pinchtab.com/install.sh | bash
# or
pinchtab daemon install
```

After that, running the bare pinchtab command performs the security setup on first use, then prints server status, the security posture, and suggested next steps.

```bash
pinchtab
```

If you would rather not run a daemon, or you are on Windows, the README offers pinchtab server for the control plane and pinchtab bridge for a single browser instance. The first real piece of work that needs no agent at all is the site audit, which writes a report and screenshots into a directory you name.

```bash
pinchtab audit https://example.com --output-dir ./audit          # report.json + screenshots/
pinchtab audit https://example.com/sitemap.xml --sitemap --sample-size 2 --output-dir ./audit
pinchtab compare https://example.com https://staging.example.com --fail-on-diff   # CI gate
```

The comment in the README says the output directory receives report.json plus a screenshots folder, and the compare form exits non-zero on a visual difference so it can gate a pipeline. For a container run, docker-compose.yml publishes port 9867 and passes PINCHTAB_TOKEN from the environment, so the token is the first thing to set before the service is reachable.

```yaml
services:
  pinchtab:
    ports:
      - "9867:9867"
    environment:
      PINCHTAB_TOKEN: ${PINCHTAB_TOKEN:-}
    shm_size: "2gb"
```

## Local-first defaults that will surprise you on first run

The security posture is the part most likely to confuse a new user, and the README does not soften it. IDPI is enabled with a local-only website allowlist, which means that by default browsing is restricted to locally hosted websites. An agent cannot reach the public internet until you explicitly allow it. The README says this restriction exists to make the security implications of browser automation clear before wider access is granted, and it labels expanding to non-local sites a security-reducing choice. Alongside that, server.bind defaults to 127.0.0.1, sensitive endpoint families are disabled by default, and attach is disabled by default. Dashboard session cookies are Secure only when the dashboard is actually served over HTTPS, and if you force server.cookieSecure = true while serving over plain HTTP, login fails explicitly instead of looping silently. There is a warning banner in the UI when you reach the dashboard over plain HTTP on a non-loopback address. Read that as a design position rather than a rough edge: the project would rather break your first request than let an agent loose on the open web by accident.

## The limits: privileged surfaces and a headless-only container

The README is unusually direct about what PinchTab is not. The dashboard, HTTP API, MCP server and remote CLI are described as privileged operator control surfaces that are not designed for untrusted users, multi-tenant exposure, or direct public-internet access. If you were hoping to run one PinchTab for a group of users, that sentence is your answer. Remote and distributed layouts are supported but framed as advanced, operator-managed deployments where you own tokens, network boundaries, TLS or reverse proxying, and which endpoint families you expose. The container image carries its own constraint: the Dockerfile states the image is intentionally headless-only, with no X11, Wayland, Xvfb or display server packages, so headed mode is not supported inside it. That matters because headed profiles are a documented feature, and the README's example of logging into a work profile to download a report is exactly the kind of task that often wants a real profile. You can still run headed on a host; you cannot do it in the shipped image. There is also an honest admission about hostile pages: even with PinchTab's content defenses on, hostile pages can increase browser attack surface and interact badly with enabled automation features.

## PinchTab compared with Playwright

Playwright is the reference point most teams will reach for, and the difference is architectural rather than a feature checklist. Playwright is a library and test runner you import into your own process, in Node, Python, Java or .NET; your test code owns the browser lifecycle, and the assertions live next to the navigation. PinchTab is a server that owns the browser, exposes it over HTTP and MCP, and expects an agent or a CLI to call in. That inverts where the logic sits. A Playwright suite is deterministic and versioned with your repository; a PinchTab session is a long-lived control plane that a model drives at runtime. The overlap is real for site audits, since PinchTab's audit and compare commands cover screenshots, console errors, broken assets, accessibility score, Core Web Vitals and security findings, territory where teams often assemble Playwright plus a handful of plugins. The reason to pick PinchTab is the agent bridge and the token-shaped output. The reason to stay on Playwright is that you want tests you can read, diff and run in CI without a daemon.

## Licence, maintenance, and what an upgrade costs

PinchTab is MIT licensed, and the repository carries a THIRD_PARTY_LICENSES.md file alongside the LICENSE, which is where you would look before redistributing a build. MIT is permissive, but the dependency graph is not uniformly so, and that file is the only place in the repository layout that speaks to the combined picture; nothing here is legal advice, and a redistribution review should read that file rather than this paragraph. On maintenance, the repository is not archived and the last push was on 2026-09-15, with releases at v0.15.2 on 2026-08-26, v0.15.1 on 2026-08-03 and v0.15.0 on 2026-07-18. That is a tight release cadence on a pre-1.0 version line, which is the real upgrade cost: minor versions can and do move. The Dockerfile pins golang:1.26-alpine and oven/bun:1, and go.mod declares go 1.26.0, so a self-hosted build needs a recent Go toolchain and a Bun toolchain for the dashboard. If you install through the shell script or the daemon subcommand, upgrades come from the project's own channel; if you build the image yourself, you are re-running the three-stage build each time, which includes the dashboard compile before the Go binary is linked.

## Conclusion

PinchTab fits a single developer or small team running agents on a machine they control, where the loopback bind and the local-only IDPI allowlist are acceptable starting points. Skip it if you need a turnkey public browser service or strict per-tenant isolation, since the README calls the dashboard, HTTP API, MCP server and remote CLI privileged operator surfaces. Before adopting, read docs/guides/security.md, confirm what PINCHTAB_TOKEN protects in your layout, and check whether your workload depends on headed profiles, since the Dockerfile states the container image is headless-only.

## FAQ

### How do you install PinchTab?

The README gives a shell installer, curl -fsSL https://pinchtab.com/install.sh | bash, and an alternative of pinchtab daemon install, which installs the server as a user-level daemon. If you prefer no daemon, or you are on Windows, you can run pinchtab server or pinchtab bridge instead.

### What is PinchTab?

It is a standalone HTTP server that gives AI agents direct control over Chrome, written in Go and licensed MIT. It exposes browser tools so agents can navigate pages, extract structured content and interact with the DOM without consuming tokens on raw HTML or images.

### How does PinchTab compare with Playwright?

Playwright is a library and test runner you import into your own process, while PinchTab is a server that owns the browser and exposes it over HTTP and MCP for an agent to drive. Their site audit features overlap, but the control model and the intended caller are different.

### What are the alternatives to PinchTab?

The README does not list alternatives. The closest comparison the documentation supports is Playwright, which differs in approach: it is a library you import rather than a server that owns the browser, so your test code controls the lifecycle instead of an agent calling an HTTP or MCP endpoint.

### How do you install PinchTab wipers?

This question is about car wiper blades, not the PinchTab browser automation project. The PinchTab repository covers installing a Go browser control server, not automotive parts, so this article cannot answer it.

## Sources

- [Issues](https://github.com/pinchtab/pinchtab/issues)
- [License: MIT](https://github.com/pinchtab/pinchtab/blob/main/LICENSE)
- [pinchtab/pinchtab on GitHub](https://github.com/pinchtab/pinchtab)
- [README](https://github.com/pinchtab/pinchtab/blob/main/README.md)
- [Releases](https://github.com/pinchtab/pinchtab/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pinchtab-pinchtab