MCP client
Codex CLI — a bearer key that never enters the config file
Codex connects to Attensira with a static key read from a named environment variable at runtime, so the credential stays out of config.toml.
Karl-Gustav Kallasmaa, Founder & CEOLast updated What you configure
The exact settings, as our documentation publishes them.
codex mcp add attensira --url https://mcp.attensira.com/mcp \
--bearer-token-env-var ATTENSIRA_API_KEY
Connecting it
In order, with the reason each step exists rather than only the instruction.
- 1
Mint a key and export it
Mint a key in Attensira's developer settings. It is displayed exactly once, because only a hash is stored — copy it into a password manager or your shell profile before closing the dialog. Export it under a name Codex can read.
- 2
Add the server with the env-var flag
Run codex mcp add with the server URL and --bearer-token-env-var naming the variable. Codex reads the token at runtime and sends it as the Authorization header itself, so the key never enters config.toml.
- 3
Make sure the variable is set where Codex launches
The variable has to exist in the shell profile Codex starts from. A key exported only in the terminal you tested in will be missing when the tool is launched another way, which presents as an authentication failure rather than a missing variable.
- 4
Fall back to a literal only if you must
If your Codex build has no support for the env-var flag, the key can be written into config.toml under an http_headers table. Treat that file as secret, keep it out of any repository, and restart Codex after editing it.
What it lets you do
- Gives a terminal-based coding agent read and, with a write-scoped key, write access to the workspace without any browser step.
- Keeps the credential in the environment rather than in a configuration file, which is the difference between a secret you rotate and a secret you grep for later.
- Uses the same endpoint and the same eighteen tools as every OAuth client, so nothing about the capability changes with the credential type.
What it cannot do
An integration page that lists only capabilities is an advertisement. This is the half you are evaluating.
- Codex connects with a static key rather than OAuth, so there is no per-client revocation: revoking the key breaks every caller using it. Mint one key per caller if you want to be able to switch one off alone.
- A key never expires until you revoke it, which is convenient and is also the reason it is worth naming keys after the thing that uses them.
- An API key is displayed exactly once and only a hash is stored, so a lost key cannot be recovered and has to be replaced.
Codex is the interesting case among the coding clients, because it takes a static key and still manages not to write one into a file. That is worth understanding, because the same pattern is the right one anywhere a key is unavoidable.
The mechanism
You add the server with a flag naming an environment variable rather than supplying the key itself. Codex reads that variable at runtime and constructs the Authorization header from it. What gets written into the configuration file is the server entry — a URL and a variable name — and nothing secret.
The consequence is that the file is boring. It can be read, shared, backed up and inspected without anybody having to think about what is in it, and the secret lives in exactly one place: your environment.
Make sure that place is the right one. The variable has to be set in the shell profile Codex actually launches from, not just in the terminal you happened to test in. A key that exists in one session and not another produces an authentication failure that looks like a bad key and is in fact a missing variable.
Minting the key
Attensira displays a key exactly once, because only a hash is stored. There is no recovery path — a lost key is replaced, not retrieved. So copy it into a password manager or export it into a profile before closing the dialog.
Choose the scope at the same time, and choose it narrowly. Read-only covers metrics, prompts, pages, sessions, automations and account details, which is the whole of what most integrations need. Write adds the ability to add prompts, create and run automations, delete things and spend credits, and scope cannot be widened after minting, so the decision is made once.
The literal fallback
If your Codex build predates the environment-variable flag, the key can be written directly into the configuration file under a headers table. It works, and it is strictly worse: the secret is now on disk in plaintext, in a file that gets copied between machines and backed up without ceremony.
If you go this route, protect the file with filesystem permissions, keep it out of any repository, and restart Codex after editing. Then treat upgrading the client as a small piece of security work rather than a cosmetic one.
What a static key gives up
Keys and OAuth reach the same endpoint with the same tools; the difference is operational rather than functional.
A key never expires until you revoke it, which is exactly what you want for something unattended and exactly what makes an abandoned key dangerous. And revocation is coarse: revoking a key breaks every caller using it, because the key is the identity. OAuth connections revoke individually, so switching one client off leaves the others alone.
The practical answer to both is the same: mint one key per caller and name it after the caller. A key called after the tool it serves can be revoked without a meeting about what else might break.
Where it fits
Codex sits between the two credential worlds. It is interactive, so a human is usually present, but its documented path here is a key. The env-var flag is what makes that acceptable — it keeps the ergonomics of a static credential without the usual cost of one, which is a secret sitting in a config file nobody remembers is there.
Rotation, since nothing forces it
A key that never expires is a key nobody is ever prompted to replace. Because Attensira cannot re-display one, rotation has a specific shape: mint the replacement first, update the environment variable where Codex launches from, confirm the tool still answers, and only then revoke the old key. Doing it in that order means there is no window in which the client is broken, and it takes about a minute — which is short enough that a calendar reminder is a reasonable substitute for an expiry the credential does not have.
Questions people ask
- Why is there no OAuth path for Codex?
- The documented connection for Codex is a bearer key. That is what the client supports here, and static keys are a fully supported credential on the same endpoint rather than a fallback.
- Does the key end up in config.toml?
- Not with the env-var flag. Codex reads the named variable at runtime and sends the header itself, so the file records the server without the secret.
- What if my build does not support that flag?
- Then the key is written literally into config.toml under an http_headers table. Protect the file, keep it out of version control, and restart Codex after editing.
- I lost the key. Can I see it again?
- No. Only a hash is stored, so Attensira cannot re-display it. Revoke it and mint a new one.
- How do I limit what it can do?
- Choose the scope when you mint the key. Read-only is enough for anything that only queries, and scope cannot be widened after minting.
Sources
Every factual statement above, with the page it came from and the date that page was read.
Attensira's connect documentation states that Codex reads the token from a named environment variable at runtime and sends it as the Authorization header itself, so the key never enters config.toml.
docs.attensira.com · retrieved
“Codex reads the token from a named environment variable at runtime and sends it as the Authorization header itself, so the key never enters ~/.codex/config.toml”
Attensira's connect documentation states that a key is shown exactly once because only a hash is stored, that Attensira cannot re-display it, and that there is no recovery path.
docs.attensira.com · retrieved
“It is shown exactly once: only a hash is stored, so Attensira cannot re-display it.”
Attensira's MCP overview states that a static API key never expires until it is revoked, in contrast to OAuth access tokens which last 60 minutes and refresh.
docs.attensira.com · retrieved
“Never, until you revoke it”