One config file,every place Codex runs
Khint writes a single entry into ~/.codex/config.toml and the CLI, the desktop app and the IDE extension all gain the same five tools. Ask what you were working on and Codex reads your live Khint session rather than asking you to describe it.
The context follows you
from the terminal to the editor
Codex is three surfaces sharing one config, which makes it the easiest of the two clients to wire and the most useful to have context in: the session that knows what this morning's ticket was about is the same one whether you asked in the terminal or in the editor.
One file, three surfaces
~/.codex/config.toml is read by the Codex CLI, the desktop app and the IDE extension alike. Khint writes it once and all three see the connector after a restart.
The context is live
get_active_context reads the working state of your current session at the moment Codex calls it, so the answer moves with your day rather than with a nightly index.
It can write back, and you will know
add_session_entry lets Codex file a conclusion into your session for your Khint agents to read next. Every write raises an OS notification and lands in an audit log.
What Codex can read
- list_sessions: enumerate your work sessions
- get_session: fetch one session by id
- get_active_context: the live compacted state of the session you are in
- search_session_entries: search across everything you logged
- All four go through a read-only database handle
What Codex can write
- add_session_entry: append a note to your active session
- Routed through a local loopback server, never straight into the file
- Bearer-token auth, with Host and Origin checks
- 60 writes a minute, an audit log, and an OS notification each time
Two minutes, and one restart
Nothing to copy and nothing to install: the binary ships inside Khint and the config is written for you.
Turn Codex on in Khint's Integrations page
Khint adds itself to ~/.codex/config.toml. That same file covers the Codex CLI, the desktop app and the IDE extension, so one toggle wires all three.
Restart Codex
Connectors are loaded at startup, so a running CLI or editor session will not see Khint until it restarts.
Ask it something only your session knows
"What am I working on in Khint?" Codex calls get_active_context and answers out of your real session.
Let it write back when it is useful
Ask Codex to save a conclusion into your session and it lands as an entry your Khint agents read next. Khint raises a notification each time.
Same five tools as Claude Desktop, and the same guarantees. The manual configuration and the full tool reference live on the MCP server page.
What it is allowed to do
Identical to every other MCP client: the door is the same width whoever is standing at it.
Reads cannot change anything
The four read tools open the local database through a read-only handle. There is no code path from a read to a write, whatever the client asks for.
Writes do not touch the database directly
add_session_entry is proxied through a loopback HTTP server inside the running Khint app, on 127.0.0.1 with an OS-assigned port, behind a 256-bit bearer token stored with 0600 permissions.
Every write is visible
An OS notification fires and the write is recorded in an audit log next to the token file. A rate limit of 60 writes a minute caps what a runaway loop can do.
Sessions only
The connector exposes your Khint sessions and nothing else. Not your history, not your agents, not your credentials, and not your connected tools.
It never leaves your machine
stdio to the client and loopback HTTP back to the app. Khint's servers are not part of this at any point.
Off is off
Turning the toggle back off removes the entry from config.toml. There is no residual process and nothing left listening.
Common questions about Codex and Khint
Does one toggle really cover the CLI, the app and the IDE extension?
Yes. All three read ~/.codex/config.toml, which is the file Khint writes. Each one picks the connector up the next time it starts, so the only per-surface step is a restart.
What does Codex actually see?
Your Khint work sessions: the list, one by id, the live compacted state of the active one, and a search across their entries. Not your action history, not your credentials, not your connected tools, and not any file on your machine.
Can Codex change my Khint data?
It can append an entry to your active session, and that is the only write. It goes through a local loopback server with bearer-token auth and a 60-per-minute rate limit, raises an OS notification, and is recorded in an audit log. The read tools use a read-only handle.
Can I run Claude Desktop and Codex against the same session?
Yes, and that is a large part of the point. Both connect to the same local server and read the same active session, so a conclusion Claude wrote into it is what Codex reads next. Neither client needs to know the other exists.
Does any of this go through Khint's servers?
No. The client talks to the bundled binary over stdio and the binary talks back to the running app over 127.0.0.1. Memory sessions are local-only and are never synced.
Give your terminal the context your editor already lost
Free with 300 credits a month. No credit card. macOS 13+ or Windows 10 22H2+.