Migrating AI Coding Assistant Instructions, Rules, and Long-Term Memory When an Account Is Lost

After you have used an AI coding assistant heavily for more than six months, your way of working changes in quiet but important ways. Global instructions contain your code style preferences. A project directory accumulates dozens of rule files. Long-term session memory captures architecture decisions and lessons learned from a repository. None of this appears on any “asset list,” yet it is the real productivity layer. If an account is suspended because of risk controls, policy changes, or mistaken enforcement, the model itself can be replaced at any time, but this context can disappear instantly. This article does not discuss any specific product’s risk-control mechanisms. Instead, it starts from a more general problem: how to turn the “context assets” scattered across a tool’s private directories into engineering capabilities that can be backed up, migrated, and versioned.

1. First, Identify What You Have Accumulated on the Tool Side

Most AI coding assistant context configurations fall into three categories. Inventory them before migrating.

1. Global instructions

These are usually stored in a hidden configuration directory under the user’s home directory, in Markdown or plain text form. They define “who you are”: code style, comment language preferences, default commit message format, and similar conventions. This part is easy to overlook because it is written once and rarely changed, but it is the “personality foundation” that takes effect in every session.

2. Project-level rules

These usually exist as a directory or a set of files inside a project repository, split by topic: one file for frontend conventions, one for testing strategy, one for deployment notes. Their value comes from being loaded on demand, and they are tightly bound to a specific repository.

3. Long-term memory

This is the most troublesome category during migration. Facts that the tool automatically summarizes and persists across sessions, such as “what build system this project uses” or “why a certain module was designed this way,” are often stored in a tool-private format. That may be JSON with metadata or a custom database file, and it is naturally incompatible with another tool’s format.

A common misconception is that a new tool’s “import” feature will make migration seamless. In practice, most import capabilities cover only session history, plugins, and skill files. Rules and memory in private formats are usually not on the list. Rather than expecting tools to be compatible with each other, it is better to take control of the format yourself.

2. Three Typical Migration Failures

Scenario 1: Path routing does not work

Some people try to point the new tool’s memory read path directly at the old tool’s directory, and it fails. The reason is straightforward: the serialization structures differ. One side may use structured records with timestamps and confidence scores, while the other uses plain-text entries. The path can point there, but the semantics cannot be parsed.

Scenario 2: Manual transfer item by item

Opening the old directory, browsing entries one by one, and copying them into the new tool can work, but it is slow and error-prone. Memory entries can number in the hundreds, and manual work also loses original creation times and associations.

Scenario 3: Migrating rules but losing memory

Rules are written explicitly; memory is accumulated implicitly. Many people finish migration only to find that the new tool knows nothing about a new project. The implicit knowledge about why things were designed a certain way remains in the old environment.

3. A Reusable Migration Pipeline

Instead of relying on a tool’s import feature, build a standardized migration pipeline with four steps.

Step 1: Inventory and locate assets

First determine the exact locations of the three asset types in the old environment. Global instructions are generally in a hidden folder under the user’s home directory. Project rules are inside repositories. The location of memory files can be confirmed by asking the tool to output its own configuration path.

# Example: inventory context assets
find ~/.config/ai-assistant -type f -name "*.md"   # Global instructions and rules
find ~/projects -type d -name "rules"               # Project-level rules
ls ~/.config/ai-assistant/memory/                   # Long-term memory

Step 2: Standardize the format

This is the core of the entire approach. Convert all three asset types into a common Markdown format and add structured metadata:

---
type: memory          # instruction | rule | memory
scope: project        # global | project
created: 2025-03-12
tags: [build, ci]
---
This project uses a pnpm workspace, and the build entry point is in packages/cli.

The advantage of Markdown is that it is human-readable, diffable, and version-controllable, and almost all tools can understand natural-language instruction text. The hard part of format conversion is memory: private formats often require a small parsing script to extract the text body and metadata fields.

Step 3: Version and host the assets

Place the standardized assets in an independent Git repository. Keep global instructions on the main branch, and isolate project rules by branch or subdirectory for each project. From then on, your context has a backup: any tool, any machine, any time, clone and restore.

Step 4: Inject into the target tool

In the new tool, configure global instructions to point to the corresponding file in the repository. Add project rules to each repository through symlinks or copies. Append memory as text to global instructions or inject it into sessions on demand. Do not dump all memory entries at once; filter by project and control the context size.

4. Going Further: Keep Context Assets Portable Over Time

Migration is only damage control. A better approach is to change your habits so that assets are portable from the start:

• Standardize at write time: When adding rules or memory, use the Markdown template above directly to avoid a second conversion.
• Sync regularly: Include the context repository in your weekly engineering routine, just like backing up code.
• Maintain a single source of truth: All tools, whether the one you use now or the one you switch to later, read configuration from this repository. Tools are only consumers; your engineering conventions are the asset itself.
• Isolate sensitive information: Memory may contain internal addresses or key fragments. Clean it before committing, and host it in a separate private repository.

Conclusion

Tools can be replaced. Accounts can fail. But the way you collaborate with AI, including those instructions, rules, and memories, should not be bound to any vendor’s private format. Treat them as engineering assets on par with code, store them in standard formats, and manage them with a version control system. Then you have the confidence to migrate at any time: losing an account means changing a runtime, not losing six months of engineering accumulation.