Give Codex an email inbox and credential vault

A Codex session can end while the account it created still matters. The next session needs the same inbox and the same service login. Keeping those resources attached to an Agent Loadout agent gives the project a place to retain them.

Here is a setup for Codex CLI. Start with email access and credential metadata. Add permission to read or create secrets only when the task requires it. You need an existing Agent Loadout agent with an inbox.

Add the remote MCP server

codex mcp add agent-loadout --url https://agent-loadout.com/api/mcp
codex mcp login agent-loadout

The login command opens the authorization flow. Choose the agent you want Codex to use and review the capabilities. Return to Codex after approval. If you already use the name agent-loadout for a different connection, choose a distinct server name in both commands.

Run codex mcp list to inspect the configured servers. The command-line setup writes Codex’s configuration for you. You do not need to maintain a second JSON configuration copied from another MCP client.

For a noninteractive environment, the agent’s Connect tab also provides a token-based configuration. Supply a scoped agent token through the environment variable named by --bearer-token-env-var. Make sure that variable is present in the process launching Codex. An organization key should stay with the backend that manages agents.

Make the first request small

Use Agent Loadout to show the connected agent and its inbox address. Then list credential names and IDs without retrieving any secret values.

The email lookup needs email:read. Listing the vault needs vault:metadata. Neither operation requires revealing a password.

Compare the agent with the dashboard before proceeding. If a credential is missing, check ownership and sharing as well as scopes. A token’s vault permissions do not grant access to every credential in the organization.

Use a service account without losing track of it

For a test, choose an app you control. Register a test account with the agent’s inbox address. Record when you submitted the form so Codex can look for mail from that attempt instead of picking an older message.

Find the verification email for the registration I just started. Use find_verification_code with the registration start time as since. Check the returned sender and screening result. Do not submit a code or open a link until it matches that registration.

After completing registration, save the account in the vault with a name that identifies the service and environment. “Issue tracker staging” is easier to manage than “API login”. Include the account username and the intended origin.

Creating a credential needs vault:write. Retrieving its stored value needs vault:use and the credential must be available for that agent to read. The MCP tools also require vault:metadata alongside those capabilities.

Decide whether Codex should receive the secret

A successful get_credential call returns the value to the client. Generating a password through the create or update tool also returns the generated value. Encryption at rest does not keep those tool results out of a transcript that your client records.

If the task only needs an approved API request or a configured login action, consider the local credential connector. It uses credentials inside a configured profile and returns the action’s result. It requires setup on the machine running it and does not support arbitrary websites without a profile.

For an authenticator code, get_totp_code returns the current code without returning its stored seed. Treat the code itself as sensitive. Do not copy it into a project note or a commit.

Leave the next session a useful handoff

Record the agent name, inbox address and credential ID in the project’s operational notes. Keep secret values out of those notes. The next session can reconnect to the same agent and request only the resource it needs.

Revoke unused tokens separately from deleting the agent. A revoked client should lose access while the team can keep the inbox and credentials for the next client. Rotate a provider credential at the provider if it has leaked; changing its stored copy alone does not invalidate the old value.

The client setup reference covers connection options. Managing passwords and API keys goes deeper into the secret-handling choices.