Four ways to read, one way to write
The asymmetry is deliberate. Reading is cheap and reversible; writing into somebody's own memory is neither, so there's exactly one write and it's the one that announces itself.
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.
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, because all three surfaces read the same local server.
Codex is three places sharing one config, which makes it the easiest of the two clients to wire and the most useful to have context in.
The asymmetry is deliberate. Reading is cheap and reversible; writing into somebody's own memory is neither, so there's exactly one write and it's the one that announces itself.
~/.codex/config.toml is read by the CLI, the desktop app and the IDE extension alike. Khint writes it once and each surface picks the connector up the next time it starts.
When Codex appends a conclusion to your session, an OS notification fires and the write lands in an audit log next to the token file. No silent injection into your own memory.
Turning the toggle back off takes Khint out of config.toml. There's no residual process, nothing left listening, and nothing to clean up by hand.
Nothing about these guarantees is client-specific: the server exposes sessions and nothing else, and it's structurally local because there's no cloud copy of a session to reach.
Security and privacyNothing to copy and nothing to install: the binary ships inside Khint and the config is written for you.
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.
Connectors are loaded at startup, so a running CLI or editor session won't see Khint until it restarts.
"What am I working on in Khint?" Codex calls get_active_context and answers out of your real session.
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.
An integration is where work comes in and goes out. These three are what happens in between.
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.
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.
It can append an entry to your active session, and that's 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.
Yes, and that's 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.
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.
Free with 300 credits a month. No credit card. macOS 13+ or Windows 10 22H2+.