What it does — use cases, paradigm, and FAQ
Open Headers chrome-extension://ablaikadpbfblkmhpmbbnbbfjoibeejb/workbench.html Test on production. Skip the deploy.
Reshape what your live site sends and receives, straight from the browser. No staging queue, no release train, no rounds of deployment approvals — point a rule at production and see the result on the very next request.
- Changes exist only in your browser — real users and prod itself stay untouched
- One toggle off and the page is back to reality
A full API client, wired into your traffic
Build, send, and organize requests without leaving the browser — everything a desktop API client does. Then chain it: any response value lands in a live variable, and any rule can inject it into real traffic. A fresh auth token on every prod request becomes one saved request.
- Collections, environments, scripts, GraphQL, OAuth 2.0 with PKCE and refresh
- Five variable scopes — vault, environment, collection, workspace, live
Chain & schedule requests. It's a full DAG.
Wire saved requests into a workflow: explicit dependencies, AND/OR run conditions, priorities — and independent steps run in parallel. Every step captures values from its response into live variables, and a refresh policy re-runs the chain so the values your rules inject never go stale.
- Capture whole body, JSON path, regex, headers, or status codes from any step
- Refresh manually, on a fixed interval, or the moment a value expires
Work solo. In a team.
Your workspace needs a home — and you pick where: in-browser today, one desktop app shared by every browser on your machine, a box on your LAN for all your devices and the people next to you, or a self-hosted server for the whole team. Same workspaces, same rules, on every tier.
- In-browser today; desktop, LAN, and self-hosted WAN tiers on the roadmap
- Team tier is enterprise-ready — SSO auth, RBAC user management, audit logs
Browser DevTools panel with a super‑charged Network tab
Open Headers ships its own panel inside the browser's DevTools: pin requests side by side, inspect waterfalls and timing phases — and turn any captured request into a rule (redirect, replace host, delay, add a header) right there. Workspace and environment switching included; the workbench never has to open.
- Capture via HAR + webRequest, or flip on Debug mode (CDP) for the full picture
- Watch your rules act live — blocked trackers, delayed calls, rewritten headers
Auto-Sync, without losing your work
Cross-device sync is where local-first products usually fold and ask you to trust their cloud. Open Headers merges at the per-field level instead: you edit a header in DevTools while a teammate rewrites the same rule in the workbench — both land, in any order, with no stale-draft banner and no overwrite.
- Per-field merge across every surface — popup, workbench, DevTools, side panel
- Scales from one extension today to daemon + desktop + CLI, and team workspaces
Local-first. The internet is optional.
"Local-first" is a posture, not a feature. The extension never needs a network to do its job — rules keep firing, requests keep running, edits keep landing. Go offline on a plane, keep working; come back online and every change merges into place. Your data, your back-end, your choice — at every step.
- No account · no cloud relay · no telemetry · no phone-home — you own it end-to-end
- Reconnect and everything auto-merges — no stale drafts, no lost work
Ask in English. Watch it happen.
Open Headers speaks Model Context Protocol, so Claude Desktop, Claude Code, Cursor, VS Code, Cline — any MCP client — can drive your workspace. Ask in plain English; the agent makes the tool calls; your workbench reflects the result. Local-only by default over stdio, HTTP/SSE when you self-host — no vendor relay in between.
- 25 tools across six domains — rules, requests, environments, variables, workflows, workspaces
- Same permissions as you — secrets stay behind the vault, sensitive operations stay opt-in
The whole product. Inside your browser. As an extension.
Every other tool in this space keeps its back-end outside the browser — a desktop app you install next to it, or a cloud you sign into. Open Headers ships the entire product, back-end included, inside the browser extension. No one else on the market does this.
- Back-end and front-end both live in the extension — install and you’re done
- No desktop app to run, no cloud to sign into, no internet required
- The architecture behind everything else in this tab
Nine rule types. One language.
Rewrite headers, block, redirect, mock, inject, delay — every rule speaks the same condition language, and the engine picks the right path to run it. Static rules compile straight into the browser's network layer and catch every request. The intercept path handles the rest — as page scripts in Standard mode, or natively over CDP in Debug mode.
- Native rules see pages, frames, fetch, XHR, images, fonts, scripts
- Body, mock, and merge rules — scripts in Standard mode, CDP-native in Debug mode
- Five variable scopes — vault, env, collection, workspace, file — in every rule
Three tools. One install.
Request shaping used to mean a desktop proxy with a CA certificate. API collections meant a cloud platform with an account. And that one header? A third tool. Open Headers ships all three categories inside a single browser extension — with one workspace store under everything.
- Proxy-grade request shaping — no CA certificate, no separate binary
- A full API client — no account, no vendor cloud
- Everything shares one store, one condition language, one UI
Open Headers — workbench 1 tab · 0 installs left over Change it anywhere. It's everywhere.
The quick popup, the side panel, the DevTools panel, and the full workbench tab are four views over the same workspace store. Flip a rule in the popup and watch it flip everywhere else — instantly, with no refresh and no save button.
- Popup for quick toggles, workbench for deep editing
- DevTools panel puts your rules next to live traffic
- All four open at once — concurrent edits just work
An IDE, not a settings page.
The workbench and the DevTools panel share one shell: top header, status footer, and two activity bars — left and right — each with its own sidebar of tools. Drag any tool tab into any of six docking zones, arrange them how you think, pick an activity-bar layout — and every new tab inherits it.
- Popup ⇄ side panel — same surface, one click apart
- Six docking zones — drag any tool tab anywhere, re-arrange freely
- Four activity-bar layouts; new tabs inherit yours
Every browser tab, its own workspace.
The workbench is a regular browser tab — so open several. Each one can host a different workspace: your personal workspace in this tab, the team's shared one in the next. Work in both at once, side by side; every edit lands in its own workspace, and nothing bleeds across.
- Open as many workbench tabs as you like — it’s just a browser tab
- Each tab pins its workspace — isolated stores, zero bleed-over
- Edit them all at the same time; every change lands where it belongs
Workbench — Personal Workbench — Team + No account. No cloud. No telemetry.
Install it and watch the wire: the extension contacts no account server, no telemetry endpoint, no cloud relay — there's nothing to phone home to. Your rules live in browser storage on your machine, and the roadmap only widens your choice of where: desktop app, local daemon, or a server you host.
- The back-end ships inside the extension — zero setup, zero servers
- Free to use, free to self-host — UI, shell & core are MIT open source
- Every roadmap back-end is yours too: desktop, daemon, self-hosted VM
The Oracle. One engine under everything.
Every change — a toggle in the popup, an MCP tool call, a teammate's edit arriving over sync — flows through one pipeline: lock the entity, put the change in order, apply, broadcast. That pipeline is the Oracle, and it never changes — only the packaging around it does.
- One mutation pipeline: lock → sequence → apply → project → broadcast
- Identical in every host — the extension today; desktop, daemon, CLI on the roadmap
- The reason saves never conflict and no surface ever goes stale
QIs it really everything inside the browser extension?
Yes — front-end and back-end. The rule engine, the API client, the sync engine, and storage all live in one install. The principle: we do everything the browser technically allows — and the few things it doesn’t, like raw-socket protocols, defer to the desktop app (roadmap), where the operating system allows more. Unplug the internet and everything still works.
QHow can an extension do what a desktop proxy does?
Static rules compile into the browser's own network layer and catch every request — pages, frames, fetch, XHR, images, fonts, scripts. The intercept path covers what that can't reach: bodies, mocks, delays. And there's no CA certificate, because we never man-in-the-middle your traffic — rules run with the page's own permissions.
QWill it slow my browsing down?
Static rules are evaluated by the browser itself, not by extension code, so the hot path costs nothing extra. Intercept rules only touch the pages they match.
QWhat's the catch? How do you make money?
There's no catch to fund: free to use, free to self-host, no account, no telemetry — and no cloud bill to pass on, because there is no cloud.
QIs it open source?
Open core, honestly labeled. The UI, the shell, and the core are MIT-licensed and public. The back-end is proprietary — that’s the intellectual property that makes working on this full-time sustainable as a long-term investment, not a side project. Most tools in this space open none of their code; here, everything stays free to use and free to self-host.
QHow do I verify the "no telemetry" claim?
Three ways. Open DevTools and watch the extension's network traffic — zero outbound requests. Capture at the system level with a packet tool like Wireshark — same answer, below the browser this time. Or read the open code: the UI, shell, and core are public, MIT-licensed.
QWhere exactly does my data live?
In browser storage, inside your browser profile, on your machine. Nowhere else — unless you later point it at a back-end you own.
QIf there's no account, how does sync work?
Today, every surface in your browser — popup, side panel, DevTools, workbench — shares one store, merged per field. Cross-device sync ships through back-ends you control: desktop app, local daemon, your own server. Never a vendor relay.
QWhat happens to my secrets and tokens?
They live in the vault scope, encrypted. Rules and requests reference them as {{vault.…}} without ever exposing values — and even AI tool calls can’t read them; sensitive operations stay opt-in.
QWhat if the project shuts down?
It won't — Open Headers is full-time work, has been for over a year, and will be for years to come. But suppose it did: nothing breaks. The extension doesn't depend on any server existing, your data stays local, and your install keeps working as-is.
QCan it actually replace my API client?
Collections with folders, environments, OAuth 2.0 with PKCE and refresh, GraphQL with schema introspection, pre- and post-response scripts, multipart file uploads — HTTP, WebSocket, and GraphQL all run right in the browser. Bring your collections over via cURL, HAR, or Postman import — Insomnia and OpenAPI are on the roadmap.
QWhat about gRPC, MQTT — raw sockets?
Browsers don't expose raw sockets, and we won't pretend otherwise. The rule is simple: everything the browser technically allows happens in the extension; where the platform stops us — gRPC, MQTT, socket-level protocols — the desktop app picks up (roadmap), same workspace, same engine, because the operating system allows more.
QWhich browsers?
Chrome, Firefox, and Edge today. Safari soon.
QDoes it work offline?
Fully. Rules keep firing, requests keep running, edits keep landing. Reconnect, and every change merges into place — no stale drafts, no lost work.
QDo I have to learn an IDE just to change one header?
No. The popup is one toggle — and every rule type ships with a pre-filled template: swap in your target URL and you’re done. The IDE-grade workbench is there when you want depth, not a prerequisite.
QWhat's live today, and what's roadmap?
- ✓Browser extension — back-end included
- ✓Nine rule types, two execution paths
- ✓Full API client
- ✓Workflows & scheduling
- ✓DevTools panel
- ✓Four surfaces, one store
- ✓Auto-sync across surfaces
- ✓Works fully offline
- ✓Open core — UI, shell & core MIT
- ▸Desktop app
- ▸Local / LAN daemon
- ▸CLI
- ▸Self-hosted web app
- ▸Git back-end — durable workspace history
- ▸Team tiers — SSO, RBAC, audit logs
- ▸MCP server for AI agents
- ▸More importers — Insomnia, OpenAPI
QWhy do some chips say "roadmap"?
Because honesty converts better than vapor. If a badge says roadmap, it isn't in the build yet — when it ships, the badge comes off. Nothing on this page pretends to exist before it does.
QCan my team use it?
Solo works today — and the engine underneath, the Oracle, is already built for concurrent multi-user editing. Team tiers arrive through infrastructure you control: a box on your LAN, or a self-hosted server with SSO, RBAC user management, and audit logs — roadmap, badged as such. Git isn’t what powers collaboration; it’s an optional durable back-end, so a new device doesn’t sync from zero — it bootstraps from the Git state and auto-syncs from there.
QDoes the AI integration send my data to a model vendor?
No. The MCP server (roadmap) runs locally; your AI client — Claude Code, Cursor, VS Code, Cline — connects directly to your installation. No relay in between, and tool calls run with your permissions: secrets stay behind the vault.
OpenHeaders
Chrome
Microsoft Edge
Firefox
Safari