Compare

You already use Claude Code or Codex. Why add Flanner?

Because of what happens to a project's context — its plans, its memory, its skills — when work moves between sessions, between agents, between machines and between people. Each agent keeps some of it. This page is what each one keeps, what it loses, and what tells you when it has gone wrong.

Every cell was read from the linked docs, repository or pricing page in September 2026, with the version named where it matters. Where the docs did not say, the cell says so. If a cell is wrong or has gone stale, tell us and it gets corrected.

Does it: the tool does this
Partly, or by hand: part of it, or a manual route
No: it does not, or does not apply
With Mesh: flanner does this on a paid Mesh plan
Not documented: the tool's own docs do not say

Your agent, on its own

Claude Code and Codex each carry some context between sessions on their own, and a docs folder in git carries whatever you commit. This is what each one keeps, what it loses, and what tells you when it has gone wrong.

Flanner beside

	Flannerplans, memory and skills as files on your disk, versioned and checked, and what each agent can reach0.16.0	Claude Codeplan mode, CLAUDE.md, auto memory, skills and pluginsv2.1.252	Codexplan mode, AGENTS.md, skills and plugins	Markdown and gita docs folder in the repository, committed
A plan, after the session ends
A plan, after the session ends	Kept A file in .plans/, every revision kept and diffable, whether or not it was committed.	One file, edited Plan mode writes one file per conversation and edits it in place, in ~/.claude/plans/, which is cleaned after 30 days. plansDirectory (v2.1.9) moves it into the project. No versions are kept.	In the thread Plan mode keeps the plan as an item in the conversation, restored when you resume. No plan file is written.	If committed A plan is a file like any other.
Evidence a plan has gone stale
Evidence a plan has gone stale	Shown A status from fresh to stale, with the evidence behind it: file references that no longer resolve, commits since it was written, and age.	None Nothing reads a plan against the code later.	None Nothing reads a plan against the code later.	git log Tells you what changed since the commit. Nothing reads the plan.
What memory loads each session
What memory loads each session	Search hits only Nothing loads until an agent searches. Each hit says why it matched.	All of it CLAUDE.md in full, plus the first 200 lines or 25 KB of MEMORY.md. Topic files on demand.	Instructions only AGENTS.md files up to 32 KiB, rebuilt every run. No memory across sessions is documented.	What you paste A file is context only when somebody puts it there.
Screens a credential before saving it
Screens a credential before saving it	Recognised patterns Known key formats, password-style assignments and long high-entropy tokens are refused. Placeholders pass. A screen, not a guarantee.	Not documented	Not documented	Manual Whatever you do not commit. Pre-commit scanners exist.
What an agent launch can reach
What an agent launch can reach	Mapped and rated Curb reads each agent's settings and rates each launch High, Medium or Low: the credentials it could read and the channels that could carry them away, with the rule behind the rating. Fixes only tighten, after your operating system asks you.	Settings, by hand Permission rules and a sandbox you configure, and /permissions lists the rules. Nothing rates what a launch adds up to.	Settings, by hand Sandbox and approval modes you configure. Nothing rates what a launch adds up to.	Not applicable
Secrets an agent left behind
Secrets an agent left behind	Swept, offline Transcripts, sessions, settings, shell history and .env files, counted by exposure class. No command prints a value.	Not documented	Not documented	Pre-commit scanners gitleaks and the like scan what you commit, not what an agent read.
Which skill copy loads when names collide
Which skill copy loads when names collide	Shown per collision Across the project, your home directory and every plugin. Claude Code layouts only.	Documented rule Enterprise over personal over project. /skills lists what loaded.	Not merged Two skills with one name both appear in the selector.	Not applicable
Moving it to another machine or a teammate
Moving it to another machine or a teammate	With Mesh Plans, memories and skills, signed device to device. Personal memory never leaves.	Commit or plugin CLAUDE.md and skills travel by commit or marketplace. Auto memory is machine-local.	Commit or plugin AGENTS.md and .agents/skills travel by commit; plugins for wider distribution.	Built in That is the job.

Plan mode in both agents is for one session: it drafts, you approve, it edits. Flanner does not draft a plan, and it does not read plan mode's file. It keeps the plans your agent saves through it, and says when the code has moved away from one.

One product at a time

Each flanner product beside the tools people use instead of it.

Memory

All four store what an agent should remember. They differ in where it lives, how much of it lands in context each session, and who else can read it. mem0 and Zep are memory infrastructure for applications you build; Claude Code's memory and flanner's are for the coding session in front of you.

Flanner beside

	Flanner Memoryone markdown file per memory, indexed on your disk0.12.0	Claude Code memoryCLAUDE.md you write, plus MEMORY.md and topic files Claude writes itself	mem0a memory API; hosted, or self-hosted under Apache 2.0	Zepa temporal knowledge graph; Graphiti is the open core, Zep Cloud the service
Where it lives
Where it lives	Your disk .flanner/memory/ in the repo, or your home directory.	Your disk CLAUDE.md in the repo; auto memory under ~/.claude/projects/.	Theirs, or yours Hosted, or self-hosted on your own vector store.	Theirs, or yours Zep Cloud, or Graphiti on your own Neo4j, FalkorDB or Neptune.
What loads each session
What loads each session	Search hits only	All of it CLAUDE.md in full; MEMORY.md to 200 lines or 25 KB.	Query hits only	Query hits only
Retrieval
Retrieval	Keyword SQLite FTS5. Each hit says why it matched.	File reads Claude reads the MEMORY.md index and opens topic files with its file tools. No index to query.	Hybrid Semantic, BM25 keyword and entity matching, scored in parallel and fused.	Hybrid and graph Semantic, keyword and graph traversal.
Knows when a fact stopped being true
Knows when a fact stopped being true	Supersede The old text stays readable under the new. No time model.	Timestamp A modified field on each file.	In the algorithm Temporal reasoning when a memory is added.	Validity windows Every fact carries when it became true and when it was superseded.
Screens a credential before saving it
Screens a credential before saving it	Recognised patterns Known key formats, password-style assignments and high-entropy tokens. Placeholders pass.	Not documented	Not documented	Not documented
Sharing with a team
Sharing with a team	With Mesh Signed, one memory at a time, on request. Personal memory never.	Commit CLAUDE.md Auto memory is machine-local and not shareable.	By the service Scoped by user and project. Unlimited end users on every tier.	By the service Per project, with MCP seats by tier.

Codex is not a column here because its docs describe no memory across sessions; AGENTS.md is instructions, rebuilt every run. Letta was left out because its memory docs could not be reached to check.

Skills

Both agents can list their skills, and Claude Code can now say how often each is used. What neither shows is which of two same-named copies is actually in effect, and neither keeps a snapshot to roll back to.

Flanner beside

	Flanner Skillsinventory, precedence, usage and safe change for skill packages0.12.0	Claude Codeskills in .claude/skills/, plugins through /pluginv2.1.252	Codexskills in .agents/skills/, plugins for distribution
Lists what is installed
Lists what is installed	One inventory Project, home directory and every plugin.	/skills and /plugin Skills in the /skills menu; marketplace plugins with version and state in /plugin.	Selector Skills appear in the $ selector. No listing command is documented.
Which copy loads when names collide
Which copy loads when names collide	Shown per collision Each duplicate, and which one is in effect.	Documented rule Enterprise over personal over project. You apply the rule yourself.	Not merged Both can appear in the selector.
Records which get used
Records which get used	Opt-in hook Explicit invocations only. The coverage window is printed beside every count.	/skill-doctor Context cost and invocation frequency. v2.1.252 or later.	Not documented
Rollback
Rollback	Snapshot Taken before every install; rollback restores it.	No Old plugin versions are purged after about 14 days.	Not documented
Team distribution
Team distribution	With Mesh A signed package, verified on arrival. Receiving is a separate step from installing.	Commit, plugin or managed settings No signing documented.	Commit or plugin $skill-installer for curated skills.
Agents it manages
Agents it manages	Claude Code Codex layouts are not read in 0.12.0.	Itself	Itself

Two community CLIs, claude-list and claude-code-plugin-manager, list what Claude Code lists, in one command. Neither adds precedence, usage or rollback.

Sharing

Getting plans, memory and skills to a teammate. Git does this well for anything you are willing to commit; a marketplace does it for skills; a hosted service does it by holding the content centrally.

Flanner beside

	Flanner Meshsigned, device to device, one item at a time0.12.0	Gitalready set up, already trusted with the source	Plugin marketplacesClaude Code's and Codex's route for distributing skills	Hosted memorymem0 or Zep, where sharing is a property of the service
What travels
What travels	Plans, memory, skills One at a time, when somebody asks.	Whatever is committed	Skill and plugin packages	Memories
Who holds the content
Who holds the content	Your machines Our servers issue accounts and access. They never receive a plan, a memory or a skill.	Your git host Which most teams already trust with the source.	A git host The marketplace repository.	The vendor Or you, if self-hosted.
Verification
Verification	Signed and checked Signed by the sending device, verified on arrival. A tampered package is refused.	Commit signing If the team set it up.	None documented	TLS To the vendor.
Receiving versus installing
Receiving versus installing	Separate steps A skill a teammate sends waits until somebody installs it.	A pull changes your tree	Installing is receiving	Not applicable
Keeps private material out
Keeps private material out	By construction A shared skill carries no record of who used it. Personal memory can never be shared.	Whatever is not ignored ships	Whatever is in the package	Scoped by user and project
Messages between teammates, delivered into the agent
Messages between teammates, delivered into the agent	With Mesh Flanner Messages, included in Team Mesh. Device to device, into Claude Code and Codex. The agent shows a message and never acts on it.	No A commit message waits until somebody reads the log.	Your own sessions Cross-session messaging (v2.1.224) passes notes between your own sessions, across machines through Remote Control and Anthropic's servers. Not a teammate's. Channel plugins can push Telegram, Discord or iMessage into a session, as a research preview. None documented for Codex.	Not documented
Setup and cost
Setup and cost	Account and subscription A workspace, a device pairing, a 30-day trial. Nothing to host.	Already done Free.	A repository and a settings entry Free.	An API key Priced per tier.

Curb

All five are about what an AI coding agent can do on a machine, and they take different routes. Snyk Agent Scan reads agent configurations for risks. NVIDIA OpenShell runs the agent inside a sandbox under its own policy. Zenity is an enterprise platform that watches and governs agents, coding agents on laptops included. TruffleHog finds secrets wherever they sit. Curb reads the settings an agent already has, says what they let it reach, tightens them and proves the result.

Flanner beside

	Flanner Curbwhat each agent launch can reach, swept, fixed and tested, on your machine0.16.0	Snyk Agent Scana scanner for agent configurations, MCP servers and skillsv0.6	NVIDIA OpenShella sandboxed runtime that runs agents under a declared policy	Zenityan enterprise platform that inventories, watches and governs agents	TruffleHoga secret scanner for repositories, files and services
What a launch can reach, as the settings stand
What a launch can reach, as the settings stand	Mapped and rated Per launch: the credentials an agent could read and each channel that could carry them away, rated High, Medium or Low with the rule and the evidence behind it.	Risk findings Fourteen scored indicators over agent configurations, MCP servers and skills, such as prompt injection, private data and secrets. Not a map of what one launch reaches.	Replaces the settings Runs the agent inside its sandbox under a policy of its own. It does not read what the agent's own settings allow outside it.	Posture Inventories coding agents and assesses their configuration: permission modes, sandbox settings and MCP connections, through hooks and OpenTelemetry.	Not applicable
Secrets an agent already saw
Secrets an agent already saw	Swept, by exposure Transcripts, sessions and prompt history, settings, shell history and .env files, each secret counted once in its worst class: sent to a model provider, readable, or blocked. No command prints a value.	In configurations Secret detection is one of its indicators, over agent and MCP configuration. Transcripts and sessions are not mentioned.	Never shown Inside the sandbox the agent never sees a real credential: OpenShell adds them only to requests bound for approved endpoints. Nothing sweeps what an agent saw outside it.	Not documented	Files and repositories Over 800 secret types, most verified live, across git, filesystems, buckets and CI. A transcript can be scanned as a file; nothing tells it which secrets were sent to a model.
Closing what is open
Closing what is open	Fixes in the agent's settings Deny rules, the sandbox, network and environment limits, written to the agent's own settings. Only changes that tighten, after your operating system asks you; a backup for 7 days and --undo.	Reports only It outputs findings and changes nothing.	A sandbox policy Kernel controls confine files and system calls, and every connection passes a policy check, from a YAML policy per sandbox. Enforcement at the operating system, which Curb does not do.	Enforce Intercepts tool calls at the moment an agent makes them, from the platform.	Not applicable
Proof that a block holds
Proof that a block holds	Tested on the real setup A decoy is planted and the installed agent is asked to read it four ways, in the same launch context and settings. Each method comes out blocked, allowed, inconclusive, not tested or unsupported.	Not documented	A check before a policy change Formal verification flags risky new access a policy change would grant before it takes effect. It does not try the agent against the result.	Not documented	Not applicable
What the agent has been seen doing
What the agent has been seen doing	Signed action log Hooks record each tool call's metadata, never content, hash-chained and signed, kept 30 days. Observed use per channel once the log covers 14 days and 20 sessions.	Not documented	Gateway log Every allow and deny decision, with destination, binary and reason, kept in the self-hosted gateway.	Runtime detection Behavioural detections on what the agent does, through hooks and OpenTelemetry.	Not applicable
One policy for every device
One policy for every device	With Mesh One signed org policy, compiled into Claude Code's managed settings, Codex's requirements and an OpenShell policy; a fleet view of each device's state; alerts. Free on every plan.	Not documented	Per sandbox A YAML policy per sandbox, kept in version control. The runtime itself manages no fleet.	Platform-wide Policy across SaaS, custom and endpoint agents from one console.	Not applicable
Agent steps in CI workflows
Agent steps in CI workflows	Rated per step Each Claude Code, Codex or Gemini CLI step in GitHub Actions workflows: what reaches it, who can start it, its secrets and tools, and whether its egress is blocked. SARIF, and a GitHub Action.	Not documented	Not documented	Not documented	Secrets in CI Scans Circle CI, Travis and Jenkins for leaked secrets. It does not read workflow definitions for agent steps.
Which agent signed a commit
Which agent signed a commit	Per-agent keys A signing key per agent, kept in the OS credential store, used only inside a recorded agent session. flanner curb verify names which key signed each commit.	Not documented	Not documented	Not documented	Not applicable

Read from each tool's own pages in October 2026, which is later than the rest of this page. Left out: Harden-Runner and zizmor check CI workflows rather than agent settings, and Curb's CI check reports whether Harden-Runner is in place; Promptfoo red-teams a coding agent in a disposable checkout rather than the installed setup; Kingfisher, which Curb's sweep uses, and gitleaks scan files and repositories as TruffleHog does; Docker's sandboxes enforce at the operating system as OpenShell does.

Works with your planning workflow

These four help you write a plan and drive an implementation from it. Flanner does neither. It has no template and no opinion on authoring; it versions whatever plan exists and says when the code has moved away from it. Use one of these to produce the plan, and flanner to keep it.

GitHub Spec Kit

A constitution, a spec, a plan and tasks, through slash commands in 30+ agents.

Writes to: specs/ in the repo
License: MIT

AWS Kiro

requirements.md, design.md and tasks.md per spec, inside its own IDE and CLI.

Writes to: Files in the project; the directory is not named in the docs
License: Free tier of 50 credits, then $20 to $200 a month

Task Master

A task graph parsed from a PRD, worked through over MCP.

Writes to: .taskmaster/ in the repo
License: MIT with Commons Clause

BMAD-METHOD

Planning, building and learning phases with agent workflows and plugins.

Writes to: docs/ and skills/ in the repo
License: MIT

Flanner tracks the markdown in one directory per project, set with flanner init --plan-dir. We have not tested it against each tool's layout. If you have, tell us what happened.

Which approach fits

Your plans are done by the end of the session and your CLAUDE.md fits in 200 lines.

Stay with your agent's built-ins. They are included and on by default.

You are building an application that needs a memory layer of its own, with the best retrieval available.

mem0 or Zep. Zep's validity windows do something flanner does not.

You are happy committing plans and skills to the repository and pulling them on the next machine.

Git. It is free, configured, and better at merging than anything we will build.

Plans do not get written, or get written badly.

Spec Kit or Kiro. Flanner has nothing to say about authoring.

You want to know what Claude Code and Codex can reach on a machine, and which secrets they have already seen, before you tighten anything.

Flanner Curb, in the same client. Free and local; the team view with Mesh.

A plan outlived the session and the code moved on; memory loads whether or not it is relevant; you have lost track of which skill copy an agent loads; or the material must not be committed or uploaded.

Flanner. Free locally; Mesh when it has to reach a teammate.

Side by side with one tool

Flanner and Plannotator

Reviewing a plan before it runs, and keeping it afterwards.

Flanner and Taskmaster

A task list for the agent, and the plan behind it.

Git or flanner for plans

Keeping Claude Code and Codex plans with plansDirectory and git, or with flanner.

Try it on one repository

One install, no account. Run it in a repository that already has a plan, and see what freshness says about it.

uv tool install flanner

Five-minute walkthrough Mesh, when it has to reach a teammate