Every time you switch AI coding tools, you start over.

You had a carefully tuned system prompt in Cursor. Custom instructions that taught the model your project's conventions. A set of code snippets you'd paste at the start of every session to give the model enough context to be useful.

Then you tried Claude Code. None of it transferred. You spent an afternoon rebuilding your setup from memory. Two weeks later, you tried Codex. Same ritual.

This isn't a switching cost. It's a tax you pay on every tool in your workflow, because AI coding context has no portable format.

What gets lost

When developers describe their AI coding setup, the same pieces show up:

System prompts and custom instructions. The rules that shape how the model behaves. "Always use TypeScript strict mode." "Prefer composition over inheritance." "Don't add comments unless the why is non-obvious." These live inside each tool's settings, in a format that only that tool understands.

Project context files. CLAUDE.md, .cursorrules, .github/copilot-instructions.md — every tool invented its own project context format. They do roughly the same thing, but they're not interchangeable.

Prompt libraries. The collection of reusable prompts you've refined over time. "Review this PR for security issues" or "Refactor this function to use early returns." These live in your head, in a notes app, or scattered across tool-specific prompt galleries.

API keys and tool configurations. MCP server connections, API endpoints, model preferences, rate limits. Each tool stores these in its own config format.

Session context and memory. What the model learned about your codebase during previous sessions. File relationships, architectural decisions, debugging history. This is the hardest piece to move — most tools don't even let you export it.

Why copy-paste is still the workflow

The most common workaround is brutally manual: developers maintain a folder of markdown files — project descriptions, architecture summaries, coding conventions — and paste relevant chunks into each new AI session.

This works. It's also terrible.

You paste a 2,000-token context document at the start of every session. That's context window budget spent on setup instead of actual work. When the project changes, you update the document. Except you have three copies in three tools, so you update one and forget the others.

Some developers have gotten creative:

# The "context bundle" approach
cat PROJECT.md ARCHITECTURE.md CONVENTIONS.md > /tmp/context.md
# Copy to clipboard and paste into AI tool
pbcopy < /tmp/context.md

This is a build system for context. The fact that developers are writing shell scripts to package context for their AI tools tells you something about the state of the ecosystem.

The format problem

Every AI coding tool has invented its own context format:

Tool	File	Format
Claude Code	CLAUDE.md	Markdown
Cursor	.cursorrules	Plain text
GitHub Copilot	.github/copilot-instructions.md	Markdown
Codex	codex.md	Markdown
Windsurf	.windsurfrules	Plain text
Aider	.aider.conf.yml	YAML

They're all storing the same information — "here's how to work in this project" — in slightly different formats that can't be read by the other tools.

This is the format problem. There is no standard for portable AI coding context. No equivalent of .editorconfig for AI assistants. No shared schema that says "here are the project conventions, the preferred patterns, the things to avoid."

What portable context would look like

A portable context format wouldn't need to be complicated. It would need:

A project description layer. What this project is, what it does, what stack it uses. Every AI tool asks for this. It should be defined once.

A conventions layer. Coding style, naming conventions, architectural patterns, things to avoid. These are project-level rules that apply regardless of which tool is asking.

A prompt library. Reusable prompts with metadata: what they do, what context they need, what output they produce. Portable across tools.

A memory layer. Facts the model has learned about the project that should persist across sessions and tools. "The auth middleware is in src/middleware/auth.ts." "The deploy script requires Node 20+." "Don't touch the legacy billing module."

A connections layer. API keys, MCP servers, external tool configurations. These are secrets and shouldn't be in the portable format itself, but the format should reference where to find them.

None of this is technically hard. The hard part is getting tool vendors to agree on a standard, and that won't happen until users demand it.

What you can do now

Until a standard emerges, the best approach is to keep your context tool-agnostic and sync it manually:

One source of truth. Maintain a single PROJECT_CONTEXT.md in your repo root. Write it in plain markdown with clear sections. Don't use any tool-specific syntax.

Symlink or generate tool-specific files.

# Generate tool-specific context files from a single source
cp PROJECT_CONTEXT.md CLAUDE.md
cp PROJECT_CONTEXT.md .cursorrules
cp PROJECT_CONTEXT.md .github/copilot-instructions.md

Or use a small script that extracts the relevant sections for each tool.

Keep prompts in a repo. Don't store prompts inside any tool. Keep them in a prompts/ directory in your project, versioned with git. Paste them when needed.

Document MCP connections. If you use MCP servers, keep a mcp-servers.json template in your repo that documents what connections are needed, even if each tool reads a different config file.

This is overhead. It's less overhead than rebuilding your setup from scratch every time you try a new tool.

The bigger picture

Context portability isn't just a convenience problem. It's the thing that determines whether AI coding tools compete on merit or on lock-in.

If switching tools means rebuilding your entire context setup, you'll stick with whatever you're using — not because it's best, but because moving is too expensive. That's not a competitive market. That's a lock-in market with the same dynamics as cloud vendor lock-in.

The tools that will win long-term are the ones that make it easy to bring your context in and take it with you when you leave. The rest are betting that the switching cost is enough to keep you.