PinchTab
A lightweight local Chrome control plane that lets AI agents drive a real browser over a token-efficient HTTP API.
- Source repo
- pinchtab/pinchtab
- Stars
- ★ 10k
- Last updated
- 4d ago
- License
- MIT
- Primary language
- Go
- FA score
- 51/100 · Major gaps
At a glance
- How it runs
- Works with
- Universal · cross-platform
- Cost
- Free, no paid service needed
- Setup effort
- Low · running in minutes
- You'll need
- Typical use
- Agent developers who need an AI agent to browse pages, extract structured content and submit forms locally without sending raw HTML or screenshots to the model.
- Not a fit if
- Teams that need to expose a browser control plane directly to the public internet
- Users expecting multi-tenant isolation or unhardened cloud deployments
- Windows-only teams that rely on the daemon workflow
- Source review
- 51/100 · Major gaps
What does this agent do, and when should you use it?
PinchTab is a standalone Go HTTP server that exposes a locally installed Chrome to AI agents as a browser control plane. The server manages profiles (cookies, history, local storage), Chrome instances, and tabs, while each managed instance is backed by a lightweight pinchtab bridge runtime. It supports headless and headed modes, multi-instance isolation, attaching to externally managed Chrome, and optional CloakBrowser stealth injection. The server binds to 127.0.0.1:9867 by default and is typically installed as a user-level daemon, with both a CLI and an HTTP API. Snapshots use accessibility-first element refs (e.g. e5) and text extraction to keep token usage low, and pinchtab audit / pinchtab compare add site audits and visual diff gates. The documented security posture is local-first: sensitive endpoint families and attach are off by default, and IDPI restricts browsing to a local-only allowlist until expanded.
PinchTab runs a server-first process model: pinchtab daemon install or pinchtab server starts the control plane, the server manages profiles and Chrome instances, and pinchtab bridge backs each managed instance. Agents drive it either via the CLI (pinchtab nav, pinchtab snap -i -c, pinchtab click e5, pinchtab text, pinchtab fill, pinchtab press) or the HTTP API: POST /profiles, POST /instances/start, POST /instances/{id}/tabs/open, GET /tabs/{tabId}/snapshot?filter=interactive, and POST /tabs/{tabId}/action. Each request carries a server token obtained via pinchtab config token --stdout. Separately, pinchtab audit produces report.json plus screenshots covering console errors, broken assets, accessibility score, Core Web Vitals and security findings, and pinchtab compare supports --fail-on-diff as a release gate.
- Agent developers who need an AI agent to browse pages, extract structured content and submit forms locally without sending raw HTML or screenshots to the model.
- Teams automating logged-in workflows: create an authenticated profile and let an agent pick the right profile to log into a work account and download a weekly report.
- QA and release engineers running
pinchtab auditin CI to catch console errors and Core Web Vitals regressions, andpinchtab compare --fail-on-diffto block visually broken releases. - Scraping pipelines that need several isolated Chrome processes running in parallel under separate profiles.
- Raspberry Pi and ARM64 users who want a local browser control plane with automatic Chromium detection.
- Users who want extra isolation and run PinchTab inside Docker so agent-driven automation executes in a sandbox.
How do you install or deploy this agent?
On macOS/Linux, use the install script, Homebrew, or npm:
curl -fsSL https://pinchtab.com/install.sh | bashbrew install pinchtab/tap/pinchtabnpm install -g pinchtabDocker deployment:
docker run -d \
--name pinchtab \
-p 127.0.0.1:9867:9867 \
-v pinchtab-data:/data \
--shm-size=2g \
pinchtab/pinchtabBuilding from source requires Go 1.26+:
git clone https://github.com/pinchtab/pinchtab.git
cd pinchtab
./dev doctor
go build ./cmd/pinchtabHow do you use this agent?
The recommended daily path is to install and start the user-level daemon, then point your agent at http://localhost:9867:
pinchtab daemon install
pinchtab daemonFor a first useful command, the CLI auto-starts the server if needed:
pinchtab nav https://pinchtab.com --snap
pinchtab snap -i -c
pinchtab click e5
pinchtab textEvery HTTP request needs the server token:
export PINCHTAB_TOKEN=$(pinchtab config token --stdout)
PROF=$(curl -s -X POST http://localhost:9867/profiles \
-H "Authorization: Bearer $PINCHTAB_TOKEN" \
-H "Content-Type: application/json" \
-d '{"name":"work"}' | jq -r '.id')
INST=$(curl -s -X POST http://localhost:9867/instances/start \
-H "Authorization: Bearer $PINCHTAB_TOKEN" \
-H "Content-Type: application/json" \
-d "{\"profileId\":\"$PROF\",\"mode\":\"headless\"}" | jq -r '.id')
TAB=$(curl -s -X POST http://localhost:9867/instances/$INST/tabs/open \
-H "Authorization: Bearer $PINCHTAB_TOKEN" \
-H "Content-Type: application/json" \
-d '{"url":"https://pinchtab.com"}' | jq -r '.tabId')
curl -H "Authorization: Bearer $PINCHTAB_TOKEN" "http://localhost:9867/tabs/$TAB/snapshot?filter=interactive"Site auditing and CI gating:
pinchtab audit https://example.com --output-dir ./audit
pinchtab compare https://example.com https://staging.example.com --fail-on-diffWhat are this agent's strengths and limitations?
- Single ~30MB Go binary with no runtime dependency; it drives a locally installed Chrome/Chromium, keeping the deployment boundary explicit.
- Documented token efficiency: text extraction is about 800 tokens per page, and the benchmark shows PinchTab is roughly 19.6%–20.3% cheaper than agent-browser at extended scope.
- Local-first defaults: binds to 127.0.0.1, sensitive endpoint families and attach are disabled, and IDPI restricts browsing to a local-only allowlist.
- Multi-instance isolation with named profiles, letting parallel Chrome processes keep separate cookies and storage.
- Built-in
pinchtab auditandpinchtab compare --fail-on-diff, which can run as a CI release gate. - ARM64 and Raspberry Pi support with automatic Chromium detection, plus
pinchtab doctordiagnostics.
- Designed for local, single-user control; the dashboard, HTTP API and MCP server are explicitly not meant for public-internet or multi-tenant exposure.
- Windows support is described as limited and best-effort, with the daemon workflow discouraged in favor of
pinchtab serverorpinchtab bridge. - The default IDPI posture blocks public internet browsing until an operator explicitly widens the allowlist.
- On macOS, driving the daily Chrome headless can prevent it from opening a normal window; a separate Chrome for Testing or Chromium build is recommended.
- Optional stealth requires a user-supplied CloakBrowser binary; none is bundled in released artifacts.
- Remote and distributed deployments leave tokens, network boundaries, TLS and reverse proxying to the operator, and are treated as advanced setups.
How does this agent compare with similar options?
The README benchmarks PinchTab against agent-browser on end-to-end agent-loop token cost using the Anthropic API: at Basic Haiku (10 steps) PinchTab is 9.5% cheaper, with 23.0% fewer requests and 17.9% fewer tokens; at Extended Haiku (24 steps) 19.6% cheaper; at Extended Sonnet (24 steps) 20.3% cheaper. No other competitors are named.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| PinchTab This agent | 51 · Major gaps | Self-hosted serviceFree | ★ 10k | 4d ago | Go | — |
| Steel Browser | 29 · Major gaps | Self-hosted serviceFreemium | ★ 7.8k | 1d ago | TypeScript | — |
| browser-control | 72 · Some gaps | CLIFree | ★ 3.2k | 1mo ago | Rust | — |
| Kuri | 71 · Some gaps | CLIFree | ★ 366 | 11d ago | Zig | — |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence shows loopback default bind, sensitive endpoint families (evaluate/macro/cookies/upload/memory etc.) disabled by default, attach disabled, IDPI on — least privilege is solidly designed (2). User confirmation exists only as documentation guidance ('Confirm with the user before account-changing actions'); there is no enforced confirmation gate in code/API, so user_confirmation is 1. Data flow transparency is reasonable: no telemetry, local-first, documented token and cookie flows (2). Sensitive data handling shows stateEncryptionKey, masked tokens, credentials not round-tripping through UI (2). Dependency security shows only go.mod and npm tests, no SBOM/audit/vuln-scan evidence, and several private pinchtab modules, so 1. External effects: browser automation can download/upload/submit forms; defaults are off but no rollback story (1). Rollback limited to daemon stop/uninstall and config reset; no undo of executed browser actions (1). Source attribution has LICENSE and author, but publisher is unverified and no signing/checksum notes (1).
Internal consistency is good: README, security.md and config.md agree on defaults (2). Dependency availability is uncertain: go.mod references private pinchtab modules and future-dated pseudo-versions, unverifiable statically (1). Failure messages are documented with concrete error codes (evaluate_disabled, tab_unfreeze_failed, memory_snapshot_too_large), fairly clear (2).
Audience and scenarios cover local single-user, Docker, distributed, QA — well described (2). Capability boundaries clearly separate server/bridge/attach and sensitive endpoint families (2). Trigger precision is thin: agent skill and MCP integration are mentioned only at install level, with no trigger conditions or selection logic (1). Environment fit covers macOS/Linux/Windows/ARM64 and flags Windows as best-effort (2).
Information architecture is clear with README, docs tree, config reference (2). Install notes cover curl/brew/npm/docker/daemon thoroughly (2). Naming stability is weakened by multiple deprecations/renames (tabEvictionPolicy→tabPolicy.eviction, browser.provider removed, browsers.config retired), creating migration burden (1). Examples and FAQ are rich (2). Known limitations have dedicated sections (Windows, macOS Chrome, cached-IP check) (2). License is MIT and complete (2). Versioning/changelog only shows a supported-versions table in SECURITY.md, no CHANGELOG (1). Maintenance responsibility has a SECURITY.md contact path but publisher is unverified and no governance notes (1).
Output usability is strong: CLI, HTTP API, structured snapshots and text extraction with clear shapes (2). Marginal value comes from token efficiency and multi-instance orchestration, differentiating from generic browser automation (2). Cost-benefit rests on self-reported benchmarks without independent reproduction and requires local Chrome plus a daemon, so benefit evidence is weak (1).
Claim traceability: most claims point to docs paths, but benchmark and performance numbers lack reproducible script references (1). Cross-source corroboration: README and security.md corroborate defaults, but benchmarks are single-source (1). Fact/inference separation: docs mix marketing phrasing ('5-13x cheaper') with factual description without clearly bounding measurement conditions (1).
- Publisher identity is unverified; the install path uses curl | bash from a remote host whose content and integrity cannot be confirmed statically.
- Browser automation inherently carries external side effects (download, upload, form submit, cookie read/write); defaults are off but there is no action-level rollback once enabled.
- go.mod references several private pinchtab modules and future-dated pseudo-versions; dependency availability and supply-chain integrity cannot be confirmed statically.
- Benchmark performance figures are self-reported without reproducible scripts or independent corroboration and should not be the sole basis for adoption.
- Multiple config keys are deprecated or renamed, implying migration cost on upgrade.
FAQ
Does PinchTab cost anything to use?
Can an agent browse public websites out of the box?
Is it safe to deploy PinchTab on a remote server?
How do you use it on Windows?
pinchtab server or pinchtab bridge directly.How does the CI gate work?
pinchtab compare accepts --fail-on-diff, so two site versions can be visually compared and the command fails when a difference is detected, making it usable as a pre-release pipeline step.