›_ Claude Code Issues
Claude Code Issues / #43013

[BUG] 🚨 `--continue` and `-p` are now seriously broken together in 2.1.90

Open 💬 17 comments Opened Apr 3, 2026 by stbenjam
💡 Likely answer: A maintainer (stbenjam, contributor) responded on this thread — see the highlighted reply below.

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

claude --continue -p "..." no longer works when the originating session was also started with -p.

WORKAROUND: export CLAUDE_CODE_ENTRYPOINT=sdk-cli (Just cli prior to 2.1.108)

Root Cause

This is caused by the 2.1.90 change: "Changed --resume picker to no longer show sessions created by claude -p or SDK invocations".

The flow is:

  1. claude -p "..." creates a session tagged with sessionKind = "print" (or similar)
  2. claude --continue -p "..." scans for the most recent session → the enrichment function filters it out because sessionKind is set → returns null
  3. loadInitialMessages sees null from the --continue block, silently falls through with no error, and starts a brand new empty session

The --continue flag should bypass the sessionKind filter, since its explicit purpose is to continue the most recent session regardless of how it was created.

Additionally, the silent fallthrough is a design issue — if --continue can't find a session, it should error rather than silently starting fresh.

What Should Happen?

--continue -p should continue the most recent session created by any previous invocation, including -p sessions. If no session can be found, it should emit an error rather than silently creating a new session.

Error Messages/Logs

No session to continue.

Steps to Reproduce

cd $(mktemp -d)
claude --max-turns 1 -p "The answer is 42. Reply only with: OK"
claude --continue # note the previous session isn't continued

Important: Must be run from a standalone shell, NOT from within a Claude session - having CLAUDE_CODE_ENTRYPOINT set masks the problem

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.89

Claude Code Version

v2.1.90, v2.1.91, v2.1.92

Platform

Google Vertex AI

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

We rely on this functionality to run Claude in CI for multi-stage workflows where each stage uses --continue -p to build on the previous stage's context.

View original on GitHub ↗

17 Comments

github-actions[bot] · 3 months ago

Found 1 possible duplicate issue:

  1. https://github.com/anthropics/claude-code/issues/42376

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

jocel1 · 3 months ago

It's related to the change from 2.1.90: "Changed --resume picker to no longer show sessions created by claude -p or SDK invocations"

stbenjam contributor · 3 months ago

Maybe similar to https://github.com/anthropics/claude-code/issues/42376? Some bad things happened to resume / continue.

For me this is a workaround:

export CLAUDE_CODE_ENTRYPOINT=cli
stbenjam contributor · 3 months ago

Actually #42376 is not quite the same, they are not using -p, but I think the causes are related.

kolkov · 3 months ago

Related — we did a full source code analysis of all resume/continue code paths in v2.1.88 TypeScript source vs v2.1.91 minified cli.js.

The --continue vs --resume vs /resume paths diverge early but converge on loadConversationForResume() in conversationRecovery.ts:456. The key difference: --continue (cli/print.ts:4908) auto-selects the most recent session via loadMessageLogs(), while --resume <id> (cli/print.ts:5075) goes through getLastSessionLog() — which has a missing leafUuids check on line 3900 that can pick a wrong message as the chain start.

Additionally, v2.1.91 introduced two more regressions in the loading pipeline:

  1. walkChainBeforeParse removed (fork pruning for >5 MB files)
  2. New ExY timestamp fallback bridges across fork boundaries

Full analysis with exact file:line references and 5 ready-made prompts for Claude Code to fix itself: #43044

Your CLAUDE_CODE_ENTRYPOINT=cli workaround makes sense — it bypasses the sessionKind filter that v2.1.90 added. The sessionKind change + the chain walking regressions = a perfect storm for context loss.

stbenjam contributor · 3 months ago

This is still broken on v2.1.92

stbenjam contributor · 3 months ago

This is still broken on v2.1.107

stbenjam contributor · 3 months ago

This is still broken on v2.1.109 and the workaround no longer works (CLAUDE_CODE_ENTRYPOINT=cli)

@bcherny Sort of desperate here, not being able to do --continue from -p originated sessions is breaking our automated multi-stage workflows :-(

stbenjam contributor · 3 months ago

New workaround:

export CLAUDE_CODE_ENTRYPOINT=sdk-cli

Chasing Claude Code internals....

stbenjam contributor · 2 months ago

Still broken in 2.1.114

<img width="925" height="152" alt="Image" src="https://github.com/user-attachments/assets/3576aac6-2962-4f61-a445-f7b51cae1f96" />

stbenjam contributor · 2 months ago

Still broken in v2.1.116.

stbenjam contributor · 2 months ago

Still broken in v2.1.117

<img width="935" height="179" alt="Image" src="https://github.com/user-attachments/assets/bf8de677-f911-4b72-b404-1f31fb09947f" />

(and now injects random whitespace before the reply)

HonorLives · 2 months ago

In v2.1.117, the behavior is more nuanced.

$ claude -p "Hi Claude, the word is serendipity."
Got it.
$ claude --continue
No conversation found to continue
$ claude --continue -p "What is the word?"
The word is **serendipity**.

Sort of confusing semantics, but seems like some thing has been done here to partially fix the problem. I don't understand why they're so intent on treating -p sessions as special.

stbenjam contributor · 2 months ago

<img width="918" height="143" alt="Image" src="https://github.com/user-attachments/assets/61e00365-b919-4036-927b-99fd68d9962c" />

Still broken in v2.1.119

stbenjam contributor · 1 month ago

This is still broken in 2.1.150.

<img width="1154" height="185" alt="Image" src="https://github.com/user-attachments/assets/95464a1d-1292-4f13-b6e1-bad96c7407bf" />

stbenjam contributor · 1 month ago

Still broken in 2.1.159.

stbenjam contributor · 29 days ago

Still a problem in 2.1.179

stbenjam@fedora:/tmp/tmp.o1TlosHU6j$ claude -p "Hello world"


Hello! How can I help you today?
stbenjam@fedora:/tmp/tmp.o1TlosHU6j$ claude --continue
No conversation found to continue
stbenjam@fedora:/tmp/tmp.o1TlosHU6j$ claude --version
2.1.179 (Claude Code)