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.

One toggle, Khint writes config.toml · CLI, app and IDE at once · same five tools as Claude Desktop

The context follows you from the terminal to the editor

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.

One file, three surfaces,
and the same five tools

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.

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.

One toggle wires all three

~/.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.

A write announces itself

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.

Off means the entry is removed

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.

The same door,
whoever is standing at it

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 privacy
The four reads use a read-only database handle
There's no code path from a read to a write
The write is proxied through a 127.0.0.1 loopback
Bearer token in a 0600 sidecar, Host and Origin checked
An OS notification and an audit line on every write
60 writes a minute, and no more
Sessions only: not your history, tools or credentials
Sessions never sync, so there's no server-side copy

Two minutes, and one restart

Nothing to copy and nothing to install: the binary ships inside Khint and the config is written for you.

  1. 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.

  2. Restart Codex

    Connectors are loaded at startup, so a running CLI or editor session won't see Khint until it restarts.

  3. 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.

  4. Let it write back when it's 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.

  5. The manual configuration and the full tool reference live on the MCP server page.

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'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.

Can I run Claude Desktop and Codex against the same session?

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.

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+.