Stop re-explaining your projectto every new chat
A blank Claude Desktop conversation knows nothing about your sprint, your blockers, or what you decided on Monday, so every good answer starts with five minutes of background you have typed before. Khint ships a local MCP server: switch it on and Claude Desktop or Codex can read the Memory session you have been working in all week, and write what it produces back into it.
The context tax:
paid again in every window
You already keep the context somewhere. It is in the meeting notes you ran an action on this morning, the error screen you captured at eleven, the Jira issue you pulled before refinement, the decision you logged after the steering call. Khint gathers all of that into a Memory session and keeps a compacted working state on top of it. What it could not do, until the MCP server, was hand that state to the other AI window you keep open: so you paste, summarise, and re-explain, and the quality of the answer quietly depends on how patient you were feeling. This page is about the direction people miss. The MCP integrations use case covers pulling Jira, Confluence, Linear, Notion, Slack and Gmail into Khint. This is the other way round: Khint as the server, your AI tools as the clients.
From one toggle to a chat that already knows
Five steps, and only the first one is setup.
Switch Khint on inside your AI tool
Open the MCP page and, under Use Khint in your AI tools, flip the Claude Desktop toggle. Khint writes the connection itself, so there is no config file to hand-edit and no key to paste. Codex has its own toggle beside it, and any other MCP client can be pointed at the server path shown under Manual setup.
Keep one Memory session per piece of work
Start a Memory sessionnamed for what you are actually on: “Checkout revamp: Q3 scope”. From then on your action runs, screen captures, notes, dropped documents and every Jira or Confluence pull land in it as entries, and Khint keeps a compacted working state on top: objective, open threads, decisions, artifacts. That working state is what the AI tool will read.
Ask in Claude's own window, without the briefing
Open Claude Desktop and ask for the thing you actually want: “draft the steering committee update for the checkout revamp”. It calls Khint for the active session's compact context, or searches your entries when you name something older, and answers from the week you really had instead of the paragraph of background you would otherwise have typed first.
Or send the request straight from the palette
You do not have to go looking for the window. Hit Cmd+Shift+K, pick Chat with Claude… under AI tools, and type the request: Khint opens a new Claude chat carrying it. With a session active and the Khint server installed, the request also asks Claude to save what it produces back into that session.
Let the answer come back into the session
When Claude writes an entry back, it joins the same session your agents read from, so the decision you reached in a long conversation is in the working state the next shortcut run sees. You get a desktop notification each time, and the write is logged, so the loop is visible rather than magic.
What the other window actually reads
Not a transcript of your day: the compacted working state Khint keeps for the session.
The grey rows are Khint's working state, rebuilt as entries accumulate so it stays short enough to be useful rather than growing into a log nobody reads. A tool can also ask for a specific session by name, or search across entries when you mention something from three weeks ago. The blue row is the return leg: an entry written back into the same session, which means the conclusion of a long conversation is waiting for your next shortcut run instead of being stranded in a chat tab. How a work session earns its context covers what goes in.
Where the line is drawn
Connecting an AI tool to your work notes should be a small, legible decision. Here is the whole of it.
Reads are read-only, and local
The four read tools open your Khint database in read-only mode on your own machine. Memory sessions never take part in cloud sync, so switching this on adds no upload path.
One write, and it announces itself
Appending an entry is the only write. It travels through a loopback endpoint in the running app, carries a token from a private file, is rate-limited and audit-logged, and raises a notification every single time.
Your palette stays yours
The server exposes sessions, not the palette. Claude cannot fire your agents, launch a workflow, or write to Jira on your behalf: those stay behind your shortcut and your confirmation.
It runs beside Khint, not instead of it
Reads work off the local database; a write needs the Khint app running, since that is what holds the endpoint. Turning the toggle back off disconnects the tool and leaves your sessions exactly as they were.
That shape is the same promise the rest of the app makes: your text goes where you send it and nowhere else, which is the point of a privacy-first AI desktop app. If you want the reverse flow as well, connecting your work tools so their content lands in the session in the first place, start from the integrations page.
Common questions
What exactly can Claude Desktop see once this is on?
Five things, and nothing else. It can list your Memory sessions with their names, status and entry counts; open one session and read its compact context and entries; read the compact context of whichever session is currently active; run a substring search across your session entries; and append a new entry. That is the whole surface. It is not a file browser and not a screen reader: it sees what you have put into a session, which is the work you chose to log, and it sees it only when it asks.
Does connecting Khint upload my sessions anywhere?
No. The Khint MCP server is a small program on your own machine that talks to Claude Desktop over standard input and output, and its reads open your local Khint database in read-only mode. Memory sessions and their entries are local-only in Khint: they are not part of the cloud sync that carries your packs and history metadata. The only thing that leaves your machine is what you yourself type or paste into a Claude conversation, exactly as before you connected anything.
Can Claude write back into Khint, and is that safe?
Yes, through one tool, and it is deliberately the most guarded path in the app. Writes do not touch the database directly: they go to a loopback endpoint inside the running Khint app, authenticated with a token stored in a private file on your machine, with origin checks and a rate limit of 60 writes a minute. Every write is recorded in an audit log next to that file and raises a desktop notification saying a Memory write came from MCP, so a write can never happen quietly. Khint has to be running for a write to land.
Do I still need Khint's own agents if Claude Desktop has the context?
They solve different halves of the day. Khint agents are short, repeatable moves you fire with a shortcut in whatever app you are already in: shape these notes into a ticket, tighten this paragraph, push it to Jira. A Claude Desktop conversation is where you think out loud about a problem for twenty minutes. The MCP server exists so those two stop living in separate worlds: both read the same session, and what you settle in the long conversation can come back as an entry the next agent run will see. The same install pattern covers Codex if that is where you work.
Let the other window catch up on its own
Free with 300 credits a month, about 10 AI actions a day. No credit card. One toggle, and your next chat starts already briefed.