1Password MCP for Codex: What the Agent Can Actually See

A coding agent needs an API key to run your app. The common shortcut is to paste the key into chat, add it to a project .env file, or place it directly in an MCP configuration. All three give the agent or the repository custody of a credential that should have stayed elsewhere.

If you are deciding which account to buy, start with the 1Password Teams vs Business calculator. This guide starts with an existing account and one disposable test credential.

The short answer

Use the 1Password Environments MCP server when you want Codex to create and manage project environment structure without receiving raw secret values through the MCP channel. Treat it as a local, interactive development control, not as a blanket guarantee that an authorized application can never leak its own environment.

Start with a fake token, keep production credentials out of the first Environment, verify every boundary below, and use a separate non-interactive identity for CI and production.

There are four different secret boundaries

The phrase “Codex cannot see the secret” is too broad unless you name the path. The current design separates four paths that should be tested independently.

• MCP tool messages: the 1Password server exposes Environment actions and variable names, but its documentation says it does not read or return raw secret values to the MCP client.
• Model context: if the secret never arrives in a tool result, prompt, terminal output, or file read, it does not need to enter the model context.
• Filesystem: a local .env mount is documented as an in-memory FIFO rather than a normal plaintext file stored in the project.
• Authorized process: 1Password injects variables into the application process at runtime. That process can use the value, which means its code, dependencies, logs, crash reports, and outbound requests remain part of the threat model.

The current 1Password MCP server guide documents the local connection, explicit authorization prompts, Environment actions, FIFO mount, and runtime injection path.

Check the current beta requirements, not an old setup post

The integration is still marked beta. The current developer guide says Codex support is available on macOS and Linux. Older sources are narrower: the original GitHub plugin README and marketplace listing say macOS only and refer to an absolute app-bundle binary path.

On 24 July 2026, the locally installed 1Password for Mac 8.12.28 app contained both 1password-mcp and the older onepassword-mcp binary names. That confirms the package contents on this machine, not that Labs is enabled or that every account has access.

The 1Password for Mac release notes first list the Codex integration in version 8.12.21. The supported current command in the developer guide is 1password-mcp, so use that name instead of copying the older absolute path.

• Install and sign in to the current 1Password desktop app.
• Create a 1Password Environment with a fake value for the first test.
• Use a current Codex local client with MCP server support.
• For an Enterprise Password Manager account, have an administrator enable the Local MCP server policy under Agentic permissions.
• For a personal account, enable the experiment in 1Password Labs.

Connect Codex using the supported command

1. In 1Password, open Settings, then Labs, select MCP Server, and enable the local MCP server.
2. Open Settings, then Developer, and select Integrate with MCP clients.
3. In Codex, open MCP servers, add a server, turn it on, and use 1password-mcp as the launch command.
4. Keep the first Environment limited to one fake credential such as TEST_TOKEN=fake-not-a-real-key.

[mcp_servers.1password]
command = "1password-mcp"

Use the Codex UI when available so it writes the configuration in the format supported by your installed client. The TOML above shows the current command, not a reason to replace unrelated Codex settings.

Codex also has independent sandbox, approval, and network controls. A secret delivery mechanism does not replace those controls. Keep file access, command execution, and network destinations as narrow as the task permits.

Run a test that proves absence without revealing the value

A useful acceptance test proves that the variable exists where needed while keeping its value out of the transcript.

1. Ask Codex to list the Environment and its variable names. Confirm that TEST_TOKEN is listed but fake-not-a-real-key is not shown.
2. Ask Codex to create the local .env mount for a disposable project.
3. Check the file type without reading it. On a documented FIFO mount, test -p should succeed.

test -p .env && echo "mounted FIFO present" || echo "not a FIFO"
git status --short --ignored

1. Run a tiny program that reports only whether the variable exists. Do not print its length, prefix, hash, or value.

node --env-file=.env -e 'console.log({ TEST_TOKEN_present: Boolean(process.env.TEST_TOKEN) })'

1. Lock 1Password, repeat an Environment action, and confirm the expected authorization behavior.
2. Deny one request and confirm the task stops without silently falling back to a plaintext file or another credential source.
3. Search the repository and Git history for the fake value. Then remove the fake Environment or rotate the test value.

git grep -n 'fake-not-a-real-key' -- . || true
git log -S'fake-not-a-real-key' --all --oneline -- .

The authorized process is still trusted with the credential

Runtime injection solves storage and handoff problems. It does not make the application process harmless. Once a process receives TEST_TOKEN, code running inside that process can use it, copy it, or print it.

This is where untrusted repositories and prompt injection matter. A package script, test helper, postinstall hook, copied debugging command, or malicious instruction in a file can ask the process to send environment data to a network endpoint.

• Inspect package scripts and new dependencies before running them with a privileged Environment.
• Keep network access disabled unless the task needs named destinations.
• Do not mount production credentials while reviewing an unfamiliar pull request or repository.
• Use a fake or narrowly scoped development credential for agent-driven setup and tests.
• Rotate a credential immediately if it appears in a prompt, tool result, terminal output, screenshot, log, or committed file.

Split Environments by consequence, not convenience

One shared Environment containing local, staging, production, billing, and administrator credentials makes every approval too powerful. Use separate Environments and access groups so the routine local workflow cannot reach production by accident.

• local: synthetic or low-impact data and replaceable development credentials
• staging: its own services, database, API keys, and rate limits
• production: no default local mount and access limited to the people and workflows that operate it
• administration: separate break-glass credentials with an owner and recovery procedure

Variable names are not secret values, but names such as ACQUISITION_TARGET_TOKEN or CUSTOMER_EXPORT_BUCKET can reveal system design and business context. Use clear names without putting customer names, incident details, or confidential project codenames into metadata.

Test paths, worktrees, and restarts

Local mounts are tied to project paths. A Git worktree, cloned copy, moved directory, IDE sandbox, or remote-development session may not use the same path or desktop process.

• Restart Codex and 1Password, then repeat the fake-token check.
• Create a disposable Git worktree and confirm it does not inherit a mount unexpectedly.
• Check that .env remains ignored even though the documented mount is not a normal stored file.
• Test the actual command runner you use. A terminal, IDE, desktop app, and container may start with different environment rules.

For other coding agents, 1Password also documents a local .env validation hook. It checks whether expected Environment mounts are configured before shell execution. That is a useful guard, but it does not inspect what the eventual process does with the secret.

Do not turn a desktop approval flow into CI authentication

The local MCP server depends on a signed-in desktop app and human authorization. CI runners, scheduled jobs, production containers, and servers need a non-interactive identity that can be revoked without disabling a developer account.

Use a narrowly scoped 1Password service account or the documented platform integration for unattended work. Keep its token in the CI platform's secret store, restrict its vault or Environment access, and record an owner and rotation date.

A service account token is itself a long-lived credential unless your platform wraps it with another control. The move from desktop MCP to CI is a separate threat-model decision, not the next checkbox in the local setup.

Troubleshoot the layer that is actually failing

• Command not found: update the desktop app and confirm the supported 1password-mcp launcher is available to the Codex process.
• Server starts but no Environment appears: check account access, the Environments beta, and whether the intended account is signed in.
• Repeated approval prompts: confirm whether each request is a new Environment action before trying to weaken authorization.
• Mount exists but the app sees no variable: check the project path, the command that starts the app, the selected Environment, and the variable name before recreating credentials.
• Instructions disagree: prefer the current developer guide over the older Codex plugin README and marketplace text, then verify the installed release notes.

The original 1Password Codex plugin repository is still useful for its tool inventory, but its macOS-only note and absolute binary path reflect an earlier setup. The current developer guide is the better installation reference.

Swedish and EU teams still need an account review

A local MCP connection and in-memory injection reduce local plaintext copies, but they do not answer every organizational question. Review the selected 1Password account region, administrator access, Environment membership, support access, retention, audit records, subprocessors, and employee monitoring rules.

Document which categories of credentials may be placed in Environments and which must stay in another managed system. A developer convenience feature should not silently become the source of truth for regulated production access.

A one-week pilot can answer the real questions

• Use one disposable repository and one fake credential.
• Verify variable-name visibility, approval denial, locking, restart, FIFO type, Git status, and worktree behavior.
• Run only code you have reviewed while the test Environment is mounted.
• Record every place the fake value appears. It should not appear in the repository, prompt, terminal output, tool results, or ordinary local files.
• Rotate or remove the test credential and confirm the old value no longer works.
• Write down the separate local, CI, staging, and production identity choices before adding a real credential.

Decide from the boundary test

The integration is a good fit when your team already uses 1Password, local development needs real API access, explicit approval is acceptable, and the fake-token test proves the secret stays out of code and model-visible output.

Keep ordinary platform secrets or another manager when the workload is unattended, the desktop app cannot be part of the path, the operating system is unsupported, or production access needs a different identity and audit model.

For Git and server authentication rather than application environment variables, use the separate 1Password SSH agent and Git signing guide.

If the pilot and account model fit, check the current 1Password options. This direct tracked link currently earns no commission.

Primary sources checked

1Password MCP Server for Environments beta

1Password secure AI access workflow

1Password Codex integration architecture and availability

1Password Codex plugin source and exposed tool list

1Password for Mac stable release notes

1Password service accounts

OpenAI explanation of Codex sandbox, approvals, network, and credential controls