Continue a Claude Code or Codex Task in Cline With an Open-Weight Model

Yes: Cline Desktop can import a local Claude Code or Codex conversation and resume it with whichever provider and model you configure, including an open-weight model. It’s a useful way to move a task off a subscription-backed agent for the slower, bounded part of the work—but it is a handoff, not a live session transfer.

That distinction matters. Your files, Git state, and conversation history can come along. The old agent’s running process, permission decisions, shell state, MCP state, and implicit knowledge do not. If Claude Code was halfway through a migration while a dev server ran in another terminal, Cline won’t inherit that. Start by making the repository, not the transcript, the source of truth.

Import the session, then choose the model

Open the same workspace in Cline Desktop. In the Sessions header, choose Import, or use the session-import page in Settings. Cline scans the local stores used by Claude Code and Codex, groups the results by tool, and lets you search by title, folder, or first prompt. Pick the one task you actually want; imports are idempotent, so reopening the importer doesn’t create a pile of copies.

The useful bit is what happens after import. Cline converts the selected conversation into a Cline session that is listable and resumable, but it does not lock that session to Claude or Codex. On resume, it uses the provider and model currently configured in Cline. Set up your open-weight endpoint under Settings → Models, then select the provider and pinned model from the composer’s provider/model picker before you send the next prompt.

Pin the model. Don’t leave an aggregator or local runtime on “default” and assume it will stay put. Cline’s model catalog changes regularly, and its own changelog explicitly warns that provider defaults can move. A handoff is already one variable too many; don’t add an unannounced model swap.

For a local setup, Cline supports local-model paths through Ollama, LM Studio, and Atomic Chat. That means you can keep the continuation on your machine, with no per-request API bill, but you are buying that with hardware and latency. Cline’s documentation puts typical local throughput at roughly 5–20 tokens per second and suggests 32 GB RAM as a practical floor for entry-level 4-bit models. That’s fine for a review, a test-fix loop, or completing a well-scoped implementation. It is not a great moment to ask a smaller model to rediscover six architectural decisions from a 200-message task.

Do a three-minute state check before the model touches code

Before resuming the imported chat, inspect the repository yourself. The imported transcript explains intent; Git tells you what exists. Run this from the workspace:

git status --short
git diff --stat
git diff --check
git log -3 --oneline

If the task has uncommitted work worth preserving, make a checkpoint you can reason about. A WIP commit is often clearer than asking a new agent to infer which of 37 changed files were intentional. If committing is against team policy, save the output of git diff somewhere outside the repo and keep the scope tight.

Then resume the imported session with a prompt like this:

You are continuing an imported agent session in this repository.

Before editing:
1. Read the imported-history summary and inspect the current working tree.
2. Run `git status --short`, `git diff --stat`, and the relevant test command.
3. State: the intended outcome, what is already implemented, what remains, and any conflict between the transcript and the repository.
4. Do not edit files until you give that assessment.

Continue only the remaining work. Keep the existing approach unless the tests or current code show it is wrong.

That first no-edit turn is cheap insurance. It catches the common failure mode where the old transcript says “next, update the API client,” but the client has already been changed, renamed, or reverted. It also tells you whether the open-weight model can follow the thread before it gets write access.

Expect a summary, not raw tool-call replay

Cline deliberately summarizes foreign history on the first resumed turn instead of replaying the source agent’s tool calls. That avoids a Claude Code or Codex transcript teaching the new agent to invoke tools Cline doesn’t expose in the same way. The original transcript is retained, and the imported-history summary is persisted after that first resume.

This is the right trade-off, but it has a cost: a summary can omit the one rejected approach that matters. If the previous agent spent 20 minutes proving that a particular dependency upgrade breaks a production compatibility path, put that fact in the continuation prompt explicitly. Don’t assume the imported summary will preserve every negative result, command output, or caveat buried in tool chatter.

Give the open-weight model the part it can actually finish

The best switch point is after the frontier model has done expensive discovery: it mapped the codebase, identified the bug, chose an approach, and made most of the risky edits. Move to the open-weight model for mechanical completion: adding tests around known behavior, fixing lint and type errors, applying the remaining repetitive changes, updating docs, or running a constrained verification loop.

Avoid switching in the middle of a vague investigation. “Figure out why checkout occasionally double-charges” is still an expensive reasoning task with lots of hidden context. “The idempotency key is dropped in createPayment; add regression coverage for retries and make the targeted test pass” is a decent handoff.

Keep approvals on for commands and edits until the first successful loop. Imported sessions do not bring Cline checkpoint history from the source tool, so you can’t treat a Claude Code or Codex rollback point as though it were a Cline rollback point. Once Cline has made a clean, tested change, its own subsequent task checkpoints are available for its work.

Finally, make completion evidence part of the prompt. Ask it to run the smallest relevant command first—say pnpm test -- src/payments/createPayment.test.ts—then the project’s normal check if the targeted test passes. An open-weight model can be perfectly adequate here, but only if the finish line is concrete. “Looks done” is where cross-agent handoffs get expensive.