Skip to main content
Cordon ships dedicated integrations for Claude Code, Codex, and Hermes. For anything else — a Next.js app, a Python service, a Go binary, a shell script — you route traffic through cordon by setting a handful of environment variables. This guide documents that contract.

​
The env-var contract

Cordon terminates TLS locally, which requires the calling process to:
  1. Send HTTP(S) traffic through http://127.0.0.1:<cordon-port>, and
  2. Trust the cordon CA so the terminated TLS handshakes validate.
The env vars below express both. They are the same vars every cordon integration sets under the hood — there is nothing special about “generic” mode.
VariableValueWhy
HTTPS_PROXY / HTTP_PROXYhttp://127.0.0.1:<port>Most HTTP clients honor these. <port> comes from listen in cordon.toml.
https_proxy / http_proxysamelowercase variants — required by a handful of tools (curl on some distros, wget, some Python libs).
NODE_EXTRA_CA_CERTSabsolute path to ca-cert.pemNode.js-specific. Node expects a raw cert, not a bundle.
SSL_CERT_FILEabsolute path to combined-ca.pemUsed by OpenSSL, curl, Go. These vars replace the default trust store, so they need a bundle (system CAs + cordon CA) — a raw cert alone would lose every other trust anchor.
REQUESTS_CA_BUNDLEsame combined bundlePython requests library.
CURL_CA_BUNDLEsame combined bundlecurl.
The combined bundle (combined-ca.pem) is generated at setup time by concatenating your system CA trust store with the cordon CA.

​
Getting the values

You don’t derive these by hand. cordon env prints them for the current scope’s cordon.toml: 
cordon env
Output (shell format, default): 
export HTTPS_PROXY='http://127.0.0.1:6790'
export HTTP_PROXY='http://127.0.0.1:6790'
export https_proxy='http://127.0.0.1:6790'
export http_proxy='http://127.0.0.1:6790'
export NODE_EXTRA_CA_CERTS='/Users/you/.config/cordon/projects/myapp-a1b2c3d4/certs/ca-cert.pem'
export SSL_CERT_FILE='/Users/you/.config/cordon/projects/myapp-a1b2c3d4/certs/combined-ca.pem'
export REQUESTS_CA_BUNDLE='/Users/you/.config/cordon/projects/myapp-a1b2c3d4/certs/combined-ca.pem'
export CURL_CA_BUNDLE='/Users/you/.config/cordon/projects/myapp-a1b2c3d4/certs/combined-ca.pem'
See cordon env for the full command reference (fish, dotenv, and json formats, and the --scope flag).

​
Applying them

Pick whichever fits your workflow.

​
Current shell (bash / zsh)

eval "$(cordon env)"

​
fish

cordon env --format fish | source

​
direnv (.envrc)

eval "$(cordon env)"
Reload with direnv allow after adding. Traffic from commands run in that directory flows through cordon.

​
mise (.mise.toml)

cordon env --format dotenv > .mise.cordon.env
Then reference _.file = ".mise.cordon.env" in your .mise.toml.

​
dotenv (.env)

cordon env --format dotenv >> .env

​
Programmatic / CI

cordon env --format json
Pipe into jq or parse with your language’s JSON library.

​
Verifying it works

With the env vars exported and cordon running (cordon start), make a request to a host you’ve configured a route for: 
curl -v https://api.stripe.com/v1/charges
Expect a response from the real API with cordon injecting the Authorization header on its way out. If TLS verification fails, the combined CA bundle isn’t being picked up — double-check SSL_CERT_FILE is set and points at combined-ca.pem, not ca-cert.pem. Run cordon doctor if anything feels off.

​
When to use which scope

  • cordon env (default, --scope project) reads ./cordon.toml. Use this when you have a per-project setup.
  • cordon env --scope user reads ~/.config/cordon/cordon.toml. Use this for a user-wide cordon instance shared across projects.
Scopes map to separate daemons with separate ports — see Scopes for the reference.