Compare
Forkbench vs 1Password
1Password's agent work has two halves: developer tooling that injects values into a process as it starts (the CLI, the SDKs, service accounts, Environments and an MCP server), and Unified Access, an enterprise platform for letting agents use credentials they never hold.
Updated
1Password gives an agent the use of a credential without custody of it, on every platform, through the CLI, the SDKs and its agent-access platform. Forkbench is a Mac app where the agents run, so a key is held by one Thread alongside that job's plan, notes, board and people, and is locked to its destination.
1Password reached the same conclusion we did and said it well: "The answer isn't handing agents your secrets. It is to let a user give an agent permission to use a credential without letting the agent see it." They are also, by some distance, the more widely deployed of the two, and if your company already runs 1Password this page will probably end with you keeping it. The difference is not the conclusion, it is what the permission is attached to: an item in a vault, or the piece of work the agent was put on.
| Forkbench | 1Password | |
|---|---|---|
| What it is | A Mac app where your agents run, one Thread per piece of work | A password and secrets manager, plus an agent-access platform |
| What a grant is scoped to | A Thread: its keys, its notes, its board and its people | A vault item, a service account, or a Unified Access policy |
| How the value reaches the command | The command receives the value, the agent receives the result | "injects the required variables directly into the application process when it runs" |
| A key aimed at the wrong host | Blocked and logged; the destination is set when the key is created | Not published |
| Folder scope the kernel enforces | Yes, per Thread, inherited by every process a shell spawns | Not part of it |
| Where it runs | macOS 13+ | Cross-platform; 1Password for Claude is macOS at launch |
| Browser logins and personal items | Not what it does | Yes, this is the original product |
| The work itself | Notes and a board per Thread that outlive the session | Not what it does; it holds the credential |
| Runs the agents | Yes, each in a real login shell | No; it supplies credentials to agents running elsewhere |
| Price | Free; Pro €30/mo; Team $30/seat, dropping to $20 at scale | Individual $2.99–3.99/mo; Business $8.99/user/mo; Unified Access on request |
Where 1Password is strong
- It is everywhere, and it is probably already in your company. Cross-platform, with the CLI, SDKs and IDE extensions on plans a single developer can afford: the Individual plan is $2.99 a month on the annual promo price, $3.99 after.
- The integration list is real and named: an Environments MCP server on the Cursor marketplace, a trusted access layer for OpenAI Codex, and 1Password for Claude filling logins in the browser without the model seeing the value.
- Business at $8.99 per user a month bundles CI/CD and infrastructure-as-code integrations, which is a whole class of work that has to happen off your laptop.
- They publish where they will not go, which is rarer than it should be: "we will not use MCP to expose raw credentials or secrets", and MCP is scoped to read-only organisational metadata rather than to the secrets themselves.
- It is a password manager as well, so it covers the browser logins, the recovery codes and the shared family or team items that a developer tool has no business holding.
Where Forkbench differs
- The permission is attached to a piece of work. A Thread holds its own plan, its own notes, its own keys and its own people, so what an agent may reach follows the job it was put on rather than the vault it was pointed at.
- Put the key in Vault and the command that needs it receives the value while the agent receives the result, so the key stays out of the prompt, the command line and the transcript. It is containment rather than a guarantee: a command you authorised can still print what it was handed. Vault is part of Pro.
- A key is locked to its destination when it is created, and an agent cannot change that later. Forkbench restricts which hosts a key may reach, and blocks and logs the rest.
- Folders the macOS kernel enforces. A Thread can be locked to the folders the job is about, applied as each shell starts and inherited by every process it spawns, so a build script and a dependency's install hook are inside the same boundary.
- The rest of the job comes with it. Notes the agents read and a board they claim work from live in the same Thread as the keys, and they outlive the pane, the app and the reboot.
The bottom line
Keep 1Password. That is the honest answer for almost everyone reading this: it is cross-platform, it is already deployed where you work, it covers browser logins and team items a developer tool should not touch, and the developer tier costs less than a coffee. What it cannot do is scope a credential to a piece of work, because it does not know what the work is. Forkbench does, because the agents are running inside it, which is why the same Thread that hands over the key also holds the notes the agent reads and the board it claims from. The two coexist happily: keep the company's secrets in 1Password and put the one key a job needs into that Thread's Vault.
1Password questions
Can I use 1Password and Forkbench at the same time?
Yes, and most people should. Every Forkbench pane is a real login shell, so op run and the 1Password CLI work exactly as they do in any terminal. A sensible split is the company's secrets in 1Password and the one or two keys a particular job needs in that Thread's Vault, so the agent working that job has those and nothing else.
Does Forkbench replace a password manager?
No. Forkbench does not fill browser logins, hold recovery codes or share family items, and it has no plans to. Vault exists for the credentials an agent's commands need while it works, scoped to the Thread that work belongs to. A password manager is a different job and 1Password is very good at it.
1Password already says the agent never sees the credential. What is different here?
What the permission is attached to. 1Password attaches it to an item and to whoever or whatever is authorised to use it. Forkbench attaches it to a piece of work: a Thread holds its keys, its notes, its board and its people, a key is locked to its destination when it is created, and anything aimed elsewhere is blocked and logged. One answers who may use the secret; the other answers which job it belongs to.
Keep reading
Sources
Comparison based on publicly available information, checked on the date above. Spot something out of date? Tell us.