AI Coding Assistant Context Migration Guide: Move Instructions, Rules, and Memory

Beyond the Account: What Is Actually Hard to Port

Developers who have switched between multiple AI coding assistants may have seen this happen: an account that used to be stable suddenly receives a notice that it has been disabled after automatic review. There is no warning in advance, and afterward there is no specific reason.

A common first reaction is to check whether the network environment is clean. Developers may change network nodes, rebind payment methods, or “warm up” accounts for longer periods. Some isolate browser fingerprints or carefully maintain an old account that has been used for months. Yet suspensions still happen. Many developers also notice that newly created accounts seem to survive for shorter and shorter periods. The more carefully an account is warmed up, the faster it may fail.

One clue from community discussions deserves attention. Some developers reverse-engineered the client code of certain AI coding assistants and reported that some tools read environment features, such as system time zone or the endpoint indicated by the connection address, and use them to identify abnormal usage such as account resale or model distillation. These analyses also suggest that the judgment may not be explicitly recorded in logs. Others searching official repositories by date said they noticed subtle changes in the character order of date lines. Later community comparisons across releases reportedly found that the environment identifiers and related configuration no longer appeared. These conclusions mostly come from individual reverse engineering, and vendor public explanations are limited, so they should not be treated as definitive. Even so, this feedback shows that many developers now treat these tools as production environments.

From an engineering perspective, rather than asking whether a specific release performs environment detection, it is more useful to answer a practical question first:

• Risk-control signals are not fully transparent. Access method, runtime environment, request frequency, and payment behavior may all influence a decision. Any single variable alone is not enough to explain a suspension.
• Account warming responds to behavioral signals, not environmental signals. When judgment shifts from usage behavior to runtime environment, building reputation simply by using an account for a long time has limited value.
• Collateral damage is hard to avoid completely. Public reports show dozens of enterprise accounts from an overseas internet service company being suspended in bulk, with little explanation and no clear response channel. Many developers also report that accounts are quickly suspended after payment upgrades, and official responses to such feedback are often absent.

So the real question is not “How do I avoid getting an account suspended?” It is: After an account becomes unavailable, how much of what you have accumulated remains?

Accounts Can Be Re-created; Context Cannot

Accounts can be re-registered. Subscription fees can continue to be paid. What cannot be carried over is the context accumulated inside a tool over time:

Asset type	Typical content	Migration difficulty
Conversation records	Historical chats, complete code-change processes	Low to moderate; some tools support native import
Skills, plugins, and workflows	Reusable templates and commands	Moderate; each capability difference needs adaptation
Project rules	Coding standards, dependency constraints, testing requirements	High; many import tools do not cover them
Long-term memory	Project facts and personal preferences automatically accumulated by the tool	High; storage formats vary by tool
Global instructions and role settings	Identity settings, default answer style, language preferences	High; requires sorting, deduplication, and conflict resolution

Conversation records and skills often have existing import paths. Project rules, long-term memory, and global instructions are frequently outside supported import scopes and must be moved manually. This “partially portable” state is more costly than “completely non-portable,” because developers may mistakenly assume that switching tools will be seamless.

I encountered this myself during a migration. When moving to a new tool, its native import covered only conversation records, plugins, and skills. Long-term memory files and rule files accumulated in the old tool were not supported. I tried having the new tool read the old tool’s memory directory directly, but the two storage formats were mutually incompatible. In the end, I had to open the directory, inspect entries one by one, and copy the content into the new tool. It was slow and easy to miss things.

If you may face a similar situation, you can use the five-step process below. Each step targets one of the most failure-prone parts of migration.

The Five-Step Migration Process

Step 1: Inventory — Confirm Which Assets Actually Belong to You

Before migrating, take an inventory of assets and answer three questions for each item:

• Is it automatically generated by the tool and stored in a tool-private format? These items have the strongest lock-in, such as long-term memory entries or workspace-level rule files.
• Can it be exported as readable text? Conversation records and plugin lists can usually be exported or located in source files.
• Does the target tool have a corresponding concept? Items without a corresponding concept need to be expressed again.

A common approach is to layer context by scope:

Layer	Scope	Typical content
Global layer	User-wide preferences across all projects	Answer language, code style, comment conventions
Team layer	Conventions shared by a team	Branching strategy, code review requirements, dependency admission rules
Project layer	Conventions within a single project	Directory structure, build commands, testing requirements
Session layer	Temporary conventions within one conversation	One-off change requests, temporary debugging ideas

Project-level and team-level rules should be placed under version control and clearly isolated from session-level context. Temporary information that has been permanently written into memory should be cleaned up before migration.

Also note: The tool stores its understanding of the project, not necessarily the truth itself. During migration, verify the source of each item, delete stale entries, and fix conflicting entries.

Step 2: Extract — Turn Context into a Single Source of Truth

The correct starting point for migration is to “detach” assets from any one tool. Create an independent directory in the workspace:

ai-context/
├── global/                   # Global layer: role settings and general preferences
│   ├── role.md
│   ├── style.md
│   └── security.md
├── teams/backend/            # Team layer: shared team conventions
│   └── engineering.md
├── projects/<project-name>/  # Project layer: project conventions
│   ├── overview.md
│   ├── commands.md
│   └── conventions.md
├── memories/                 # Fact entries (one file per entry)
│   └── <memory-id>.md
├── ir/                       # Intermediate representation (unified intermediate format)
│   ├── instructions.yaml
│   ├── rules.yaml
│   └── memories.json
├── adapters/                 # Rendering adapters for each tool
├── sessions/                 # Optional: redacted conversation records
└── VERSION                   # Version identifier

Put this directory under version control and make it the single source of truth. From then on, regardless of which tool is used, configurations are rendered from this source. Do not let tools hold the original context themselves.

Step 3: Normalize — Use a Unified Intermediate Representation to Remove Format Differences

Tools store context in very different ways: some use plain-text rule files, some use individual memory entries, and some include priority and scope fields. Copying files directly leads to a combinatorial problem of “N sources × M targets.” A better approach is to introduce a unified intermediate representation (IR): first convert each source into a common structure, then have an adapter layer render it into the target tool’s format.

Rules can be described declaratively:

# ir/rules.yaml
schema: "1.0"
rules:
  - id: ts-no-explicit-any
    title: Prohibit using the any type
    type: code-standard
    scope: project                     # global | team | project
    applies_to: ["**/*.ts", "**/*.tsx"] # applies by path; if unmatched, applies to all files
    excludes: ["**/generated/**"]
    statement: New code must not declare the any type. If bypass is truly necessary, document the reason and an alternative.
    priority: 70                       # 0-100; higher values have higher priority
    conflicts_with: []
    source: projects/example-project/conventions.md

Instructions use a similar structure, with a when field describing the applicable scenario:

# ir/instructions.yaml
schema: "1.0"
instructions:
  - id: feedback-format
    title: Code review feedback format
    type: feedback
    priority: 50
    when: "scenario is code review"
    statement: Use a three-part output: problem / impact / recommended change. Use plain language when identifying real issues, and avoid vague judgments.
    source: global/style.md

Each memory record includes source, applicable scope, and confidence, providing the basis for later conflict resolution:

{
  "schema": "1.0",
  "memories": [
    {
      "id": "auth-gateway-jwt",
      "category": "architecture",
      "statement": "User authentication is handled by the API gateway. Business services only validate JWTs and do not maintain session state.",
      "scope": "project:demo-order-service",
      "confidence": 0.9,
      "last_verified": "2025-11-02",
      "source": "sessions/2025-10-28-auth.md",
      "derived_from": ["gate-config-token"],
      "supersedes": []
    }
  ]
}

Once items are abstracted from “chat records” into “type + applicable condition + statement + priority + source,” they can exist independently of any tool’s format. The rendering layer only needs one mapping per target format:

def render_rule(rule: dict, target: str) -> str:
    """Render a rule from the unified intermediate format into the native format of the target tool."""
    statement = rule["statement"].strip()
    if target == "markdown-rule":
        # For path-scoped rules, express them as "path + requirement".
        if rule.get("applies_to"):
            paths = ", ".join(f"`{p}`" for p in rule["applies_to"])
            return f"- **{rule['title']}** (applies to {paths}): {statement}"
        return f"- **{rule['title']}**: {statement}"
    if target == "json-rule":
        import json
        return json.dumps(
            {k: rule[k] for k in ("id", "title", "statement", "priority") if k in rule},
            ensure_ascii=False,
        )
    raise ValueError(f"Unsupported target format: {target}")

Step 4: Rebuild Memory — Move from “Manual Copying” to “Fact Deduplication”

Long-term memory is the part most likely to go wrong during migration. There are three common reasons:

• Entries are often automatically extracted by the tool during conversations, without a unified structure.
• The same fact may be recorded multiple times with different wording.
• After a project evolves, early entries may no longer be valid.

Rebuild memory in four steps:

1. Categorize. You can organize entries into categories such as:

   • Architecture decisions;
   • Tech stack and dependency versions;
   • Coding conventions;
   • Environment and deployment configuration;
   • User preferences;
   • Known issues and temporary states.

   The last two categories should not be written into long-term memory by default. If they must be kept, add an expiration date.

2. Deduplicate and merge. Use “subject + attribute + value” as the matching key. Merge semantically similar entries into one, while preserving all source references.

3. Resolve conflicts. When two entries point to the same attribute but have different values, decide in the following order:

   1. Check code, configuration, or documentation;
   2. Compare last_verified;
   3. Compare confidence;
   4. If still unresolved, mark it as pending confirmation and do not write it into the target tool.

   Replaced entries should be recorded in the supersedes field.

4. Verify after migration. Turn key facts from memory into executable checks. When an entry has a code or configuration basis, it can be verified quickly during the next tool switch:

# Example: verify a tech-stack fact stored in long-term memory
# Entry: authentication is handled by the API gateway, and business services only validate JWTs
test -f deploy/gateway.yaml || { echo "Gateway configuration is missing: update memory auth-gateway-jwt"; exit 1; }
grep -q "jwt" deploy/gateway.yaml || { echo "JWT validation configuration was not found in the gateway: update memory"; exit 1; }

Step 5: Capability Mapping and Regression Verification — Migration Is Not Done Until Verified

Source tools and target tools do not have identical capabilities. For example, some tools support custom skills, subagents, and background tasks, while others only provide conversation, file read/write, and command execution. During migration, build a capability mapping table and mark each capability as “direct migration,” “transformed migration,” or “no migration”:

Source capability	Direct migration	Transformed migration	No migration
Global instructions, project rules	Rules and preference entries	—	—
Long-term memory	Architecture facts, tech stack, coding conventions	Rewrite user preferences as style rules	Entries containing account credentials, secrets, or internal addresses
Skills / plugins	Import when supported by the target tool	Rewrite as prompt templates with input/output descriptions	Skills that depend on source-specific runtimes
Subagents / parallel tasks	Map when supported by the target tool	Split into step-by-step tasks orchestrated by the main workflow	When no equivalent mechanism exists, declare in rules that the main workflow must execute them sequentially
Conversation records	Import when supported	Distill into fact entries	Segments containing sensitive information

Strong constraints in rules should also be rewritten into a form executable by the target tool. For example, if the source tool requires “run tests automatically after code changes,” but the target tool has no corresponding hook, it can be rewritten as:

After modifying source code, run <test-command> first. Only finish the current task after all tests pass, and report the result.

Finally, use regression verification to confirm that migration is complete. Recommended flow:

Export context -> scan for sensitive information -> redact -> generate IR -> conflict check -> trial run (no writes) -> formal write -> behavior verification

from pathlib import Path
# Skeleton of the migration flow; replace each step with an actual implementation
def migrate(src: Path, dst: Path, target: str, apply_changes: bool = False) -> list[str]:
    """Migrate context from the source tool to the target tool and return a list of issues."""
    issues: list[str] = []
    context = src / "ai-context"
    # 1. Scan for sensitive information: common secret prefixes, private keys, internal addresses, etc.
    issues += scan_secrets(context)
    # 2. Convert each source into the unified intermediate representation (IR)
    ir = build_ir(context)
    # 3. Check for conflicts and duplicate entries; report only, without automatic resolution
    issues += check_conflicts(ir)
    # 4. Render and write. In trial mode, only generate files in a temporary directory for diffing.
    (dst if apply_changes else Path("/tmp/migration-preview")).mkdir(parents=True, exist_ok=True)
    for item in ir["rules"]:
        write_rendered(dst if apply_changes else Path("/tmp/migration-preview"),
                       item["id"], render_rule(item, target))
    return issues

Behavior verification does not need to be complex. Select a few high-frequency rules from the migrated configuration, such as language preferences, code style, or testing requirements, and run a real task in a test project to see whether the output matches expectations. Also use local Git to keep both pre-migration and post-migration versions. If the new configuration causes abnormal behavior, you can roll back at any time.

Five Common Migration Failure Modes

Mixing Configurations from Two Tools

Writing old and new configurations together makes it hard to identify which rule caused a problem during rollback. Use an independent directory during migration, and switch the active scope only after verification passes.

Treating “Code Style Preferences” as Engineering Standards

Personal preferences belong in global instructions. Engineering standards should be placed in lint configuration, formatting configuration, and CI checks. Whenever a tool can enforce a rule, do not rely on prompts alone.

Letting Rules Grow Without Limits

The more rules there are, the higher the chance of conflict, and the less likely the model is to follow any single rule. Audit rules regularly: delete rules that never took effect, merge duplicate entries, and record the source for each rule.

Letting Memory Only Grow and Never Change

If a memory store lacks a review mechanism, stale entries will keep interfering with judgment. Set a review cycle for fact entries, such as once per quarter, and use scripts to verify them periodically.

Exporting Secrets and Internal Addresses Along with Instructions and Memory

Instructions and memory often contain API keys, internal domain names, database connection strings, and other sensitive information. Once exported to an uncontrolled storage location, the risk increases significantly. Principles:

• Scan and redact before migration;
• Rotate exposed credentials immediately;
• Do not upload context containing sensitive information to public repositories or third-party platforms;
• When necessary, inject credentials through a controlled credential management mechanism rather than writing them in plaintext configuration.

Include Portability in Tool Selection

Migration cost depends heavily on how context is managed day to day. Instead of rescuing assets after an account becomes unavailable, treat portability as a design goal for daily work:

• Versioning. Keep the context directory under version control so every change is traceable and reversible.
• Periodic drills. Run a full migration drill each quarter to verify that export, redaction, and rebuilding still work.
• Prefer neutral formats. Store context primarily in readable, parsable neutral formats. Generate tool-native configuration with scripts instead of maintaining it manually.
• Isolate sensitive information. Store credentials separately from context and inject them through controlled methods.
• Define a backup policy. Individual developers can use version repositories or object storage for off-site backups. Enterprise teams can combine image repositories, container platforms, and related infrastructure to keep version history and multiple replicas, while defining retention periods and recovery procedures.

In other words, an account can be treated as a replaceable external resource. Context assets are engineering assets that need to be managed over the long term.

Conclusion

Account risk-control rules are not controlled by developers, but how context assets are managed can be controlled by developers. If instructions, rules, and memory are stored as versioned, format-neutral, and verifiable engineering assets, the cost is just a few extra minutes of routine organization. The benefit is the confidence to switch freely between any tool or platform.

The next time you face the choice of “Should I switch to a different coding assistant?” ask first: If I had to leave tomorrow, could I take my full context with me within one day?