Assistants

stratless reads your assistants’ own history and loads a profile back into them. Those are two separate jobs, and they no longer roll out at the same speed.

Reading your sessions is per-tool work: every assistant keeps its history somewhere different, in its own shape, with its own cleanup to guard against. That arrives one tool at a time.

Loading the profile is solved for everything at once. stratless mcp serves it over the Model Context Protocol, so any assistant that speaks MCP can read your profile without stratless knowing anything about that tool’s files.

So the honest answer to “does it work with X” has two halves: whether your profile can reach X today, and whether X can contribute to your profile yet.

Supported today

Two of them — and each gets its own profile. How you work with Claude Code and how you work with Codex are two different collaborations, so stratless builds HUMAN.claude-code.md from your Claude Code history and HUMAN.codex.md from your Codex history, and never measures one against the other. A behaviour observed in one tool is never presented to the other as a claim about it.

Claude Code

• Reads ~/.claude/projects: JSONL transcripts, one per session.
• Loads its own pair’s profile — ~/.stratless/HUMAN.claude-code.md — imported by your ~/.claude/CLAUDE.md, so it loads at the start of every session.
• Borrows claude -p to read your history and write the profile, on your own subscription.
• The reaper: Claude Code deletes transcripts after 30 days, per file. stratless init stops that (it sets cleanupPeriodDays to 3650) and archives everything it can still reach. This is the one thing you cannot do later.

Codex

• Reads ~/.codex/sessions: JSONL rollouts, nested by date.
• Loads the profile into ~/.codex/AGENTS.md, as a copy rather than a link. Codex expands no import syntax, so the text itself goes in between markers and is rewritten on every build. If you keep an AGENTS.override.md, the profile goes there instead, because Codex reads that file instead of AGENTS.md rather than as well as it.
• Borrows codex exec to name your patterns and word your profile, on your own subscription.
• The refresh asks you first. init writes a SessionEnd hook into ~/.codex/hooks.json, and Codex treats any new hook as untrusted until you approve it in its own review screen. So stratless reports needs your approval rather than claiming the refresh is on, and keeps saying so until you have approved it. That approval is yours to give inside Codex. We never write it for you.
• No reaper. Codex does not delete your rollouts on a timer, so there is nothing to switch off and nothing to rescue. stratless still keeps its own copy, which guards against one you delete by hand later.

Each profile is worded by its own assistant. The voice is part of the pair: your Codex profile is written by codex exec on your own ChatGPT plan, your Claude Code profile by claude -p on your own Claude plan. When a pair’s assistant is not installed as a command-line tool, the build borrows whichever assistant is present rather than refusing — a profile in a borrowed voice beats no profile — and every build records which model actually wrote it, so if a profile ever starts reading differently, the reason is in the record rather than left to guesswork.

One difference between the two borrows is worth stating plainly rather than averaging away. The Claude Code borrow runs with no tools at all. The Codex borrow runs read-only, in an empty directory, with a scratch config, which the operating system enforces rather than a flag we pass. That is stronger in one way and weaker in another: it does not depend on a switch being honored, but it is containment rather than an absence of hands, so a Codex borrow could in principle read a file where a Claude borrow could not. Neither can write anything, and neither can see your profile.

Your profile, in anything that speaks MCP

Run stratless mcp and point an assistant at it, and it can read your profile. No reader, no adapter, nothing per-tool. One config line, verified working today in:

• Cursor, which receives the profile at connect time, before its first answer.
• Claude Desktop, which receives it when the assistant asks for it. Your chats there are not readable by us, so this is one-way: the profile arrives, nothing flows back.
• Claude Code, which already gets it as a file, so nothing changes there.

Anything else that speaks MCP should work the same way, including local agents that have nothing to do with code. Setup is in Commands. None of it opens a network connection: the assistant starts stratless as a program on your own machine and reads the answer back over a pipe.

Reaching a tool is not the same as fitting it. Your profile is derived from how you work with a coding assistant, so what travels is the part that is about you: how you write, what you ask for, when you want a plan before the work starts. What travels less well is anything tied to a particular tool’s way of doing things. A general-purpose assistant reading your profile gets a real description of you and some detail it has no use for. That is worth knowing before you point everything you own at it.

Contributing to your profile is the separate half, and it arrives one tool at a time.

Next to read: the CLIs

Cline and Copilot keep local session logs detailed enough to carry both sides of a conversation, which is what the profile needs. These come next: the same HUMAN.md, a per-tool reader.

Gemini CLI is not on that list, and will not be. Google stopped serving it in June 2026 and replaced it with a closed-source successor whose history we cannot read. The open codebase survives as Qwen Code, which is where that work would go instead.

Harder to read: the GUIs

Cursor, Zed, and Windsurf keep their histories in undocumented database blobs rather than clean logs, so reading them is messier and more fragile. Your profile already rides out to them over MCP; what is missing is the other direction.

Want yours supported?

If your assistant keeps a local, readable history, it can work. Open an issue and tell us which one.