AI Coding Tool Exit Drill: Portability of Rules, Task State, and Audit Evidence
Being able to export chat JSON doesn't mean you can leave a coding tool. This article defines a content-addressed exit package covering repository rules, task checkpoints, approvals, tool configuration, and audit receipts, and uses a cold start with an alternative tool to prove migration and revocation are truly complete.
Key Points
- Topic Focus: AI Agent、DevOps、开源
- Suitable for: indie hackers, full-stack engineers, AI application developers
- Core value: quickly understand background, practical paths, common pitfalls, and engineering advice
A vendor may provide an "export conversation" button, yet a team still might not be able to exit: repository instructions exist only in the cloud, approvals aren't linked to actual execution, unfinished tasks lack working trees, MCP configuration contains vendor-proprietary IDs, historical indexes can't be rebuilt, and the old GitHub App still retains write permissions. Comparing only generation quality at procurement time defers migration costs until a price hike, an incident, or a compliance deadline exposes them. AI Coding Tool Comparison answers day-to-day capability differences; this article positions the exit drill as a hard gate in tool selection.
First, enumerate what must be taken along and what must be left behind
The organization publishes coding.toolExitScope.v1, enumerating tenant, repository, user, and time scope, along with the migration, archive, or destruction policy for each object class. Objects include at minimum repository rules, Prompt templates, tool/schema configuration, permission policy, tasks and attempts, human approvals, patches and worktree checkpoints, command receipts, evaluation results, model/cost summaries, memory and index-generation configuration, exceptions, tombstones, and external integrations.
Raw model reasoning, vendor security-detection details, or third-party restricted content may be legally non-exportable; these must appear as an explicit NON_EXPORTABLE type with a reason and alternative evidence, not silently absent. Credential values never enter the exit package—only secret references, usage, and revocation status are retained. Personal data is filtered according to current consent and retention policy; deleted objects emit a tombstone so the new system cannot re-import them from old backups. AI Application Data Privacy provides general lifecycle requirements; here we apply them to the tool-migration checklist.
exitPackage.v1 must be self-describing
The exporter generates coding.toolExitPackage.v1, pinning the scope digest, vendor tenant, cutoff/watermark, schema version, object counts, per-class manifests, blob digests, relationship edges, redaction policy, missing items, and signature. All IDs use a stable namespace within the package and retain a restricted mapping to original IDs; timestamps carry timezone and clock semantics. W3C PROV's entity/activity/agent can express tasks, executions, patches, and reviewer relationships, but the package must also define a precise enumeration for every business state.
schema: coding.toolExitPackage.v1
scope: sha256:31d...
watermark: event:018f...
objects: { rules: 42, tasks: 318, receipts: 1904, tombstones: 27 }
blobs: cas-manifest@sha256:91a...
missing: [{ type: model-reasoning, reason: non-exportable }]
Git commits and reachable objects can be carried by a Git bundle, but dirty working trees, untracked fixtures, and LFS require separate manifests. Coding Agent to Developer Handoff Checkpoint defines single-task handoff; the exit package aggregates the entire tool tenant, referencing each checkpoint digest without reinterpreting completeness. Command facts reference Verifiable Transcript, preventing editable chat text from being passed off as audit.
Export uses a frozen watermark rather than downtime-copy. First record the cutoff and export objects before the watermark; new events during the window go into incremental segments, and finally writes are briefly frozen and the package is CAS-sealed. After interruption, resume by object ID and digest—never renumber. The package is decoded in an isolated environment with a reference reader; any unknown required type marks the whole affected task UNSUPPORTED, never dropping fields and then marking success.
Parseable doesn't mean work can continue
The drill has at least two layers. The first recomputes object counts, relationship integrity, digests, state machines, and tombstones with a neutral reader maintained by the organization; the second imports the package into another candidate tool and cold-starts it in an environment without the original vendor's API. Selected tasks must restore repository rules, read-only context, open questions, and permitted next steps; historical approvals can only be displayed, not treated by the new tool as fresh execution authorization.
Semantic conformance is validated with fixed questions: which tasks remain incomplete, which base tree a patch is based on, who approved which set of parameters, which commands truly terminated, and which tool permissions have been revoked. Search results and the old UI need not be pixel-identical, but the answers must reference the same evidence digest. OpenTelemetry trace IDs serve only as correlation material—you cannot require the new tool to access the old vendor's trace backend. Indexes migrate only the generation recipe and source watermark; the new stack rebuilds by default, avoiding carrying unexplainable vectors.
The transition contract is fixed as EXPORTING -> IMPORT_VALIDATED -> WRITE_FROZEN -> NEW_ACTIVE -> REVOCATION_PENDING -> REVOCATION_COMMITTED -> EXIT_COMPLETE. The original tool's background jobs drain before WRITE_FROZEN; after that, late comments and pushes are rejected by a repository-side fence. Old credentials are first demoted to short-lived, least-privilege leases and still not immediately revoked, preserving controlled rollback before the point of no return. The new tool must pass an observation window before OAuth/GitHub App, API key, webhook, SCIM, bot accounts, and cloud workspaces are revoked, with each provider receipt recorded individually. Agent Short-Lived Capability Leases can shorten the residual-authorization window but cannot replace revocation reconciliation.
Attack the drill with deliberately corrupted packages
A fault suite deletes hidden repository rules, truncates blobs, swaps tenant IDs, duplicates approvals, drops tombstones, fabricates a late task after the watermark, inserts an unknown required enum, makes LFS objects unreachable, tampers with timezones, rewrites source objects after the export seal, and lets an old webhook send events after revocation. The system must report the specific gap; it cannot use "99% of objects exported" to mask that a critical rule or authorization is still active.
The exit gate requires that object counts within scope are conserved per class against the source snapshot, blob digest errors are zero, dangling required relationships are zero, resurrected deleted objects are zero, representative-task cold-start recovery rate is 100%, evidence-question answer consistency is 100%, and unrevoked integrations are zero. Any UNKNOWN revocation keeps the state at EXIT_INCOMPLETE; owner and deadline are for tracking only, and the repository fence must continue blocking old identities—unknowns cannot be counted as passing. The drill runs every six months and before any major procurement renewal; the package and reader are cross-tested with the current and previous versions.
Migration first copies read-only rules and closed tasks, then migrates unfinished low-risk tasks, and finally switches the write entry point. Before REVOCATION_COMMITTED, if evidence is lost or the alternative tool misuses old approvals, the entry point can be CAS-rolled back to the old tool still under fence management, with new tasks kept frozen. Once a credential revocation is accepted by the provider, the point of no return is crossed: from there, failures can only fail-forward to a human/read-only path, or a time-limited credential can be issued via fresh approval—the old credential cannot be resurrected as a "rollback." After true completion, a minimal signed manifest and destruction receipts are still retained. This way, exit capability becomes a continuously validated engineering property, rather than an un-drillable sentence buried in a contract annex.
Related
Related Content
Article
What Is Vibe Coding? Will It Change How Programmers Work?
Technical trends, engineering practices, and an indie developer perspective on Vibe Coding, AI, and independent development.
Article
From Copilot to Codex: AI Coding Tools Enter the Agent Era
Technical trends, engineering practices, and indie-developer perspectives around AI, AI Agents, and Vibe Coding.
Article
Why Does MCP Matter? Understanding the AI Tool Protocol
Technical trends, engineering practices, and an independent developer perspective on MCP and AI Agents.
Article
Core Architecture of AI Agents: Planning, Memory, Tools, and Execution
Technical trends, engineering practices, and independent developer perspectives around AI Agents and large language models.