MagicTools
Back to Articles
Claude GuidesAugust 6, 20263 views3 min read
claude-codeheadlesstroubleshootingclaude-code-labclisession-management

Claude Code Says No conversation found to continue — Your -p Sessions Are Being Filtered Out

What the official docs say

The CLI reference gives --continue a very simple meaning: continue the most recent conversation in the current directory. No qualifiers — nothing about whether that session was started interactively or produced by a headless claude -p "..." run.

That is exactly the assumption many automation workflows are built on: scripts do the bulk work with -p, and when something needs a human, you drop into interactive mode with --continue to take over.

What actually happened

macOS + Claude Code v2.1.220, a clean empty directory, four steps (terminal is a real TTY):

$ claude --max-turns 1 -p 'The answer is 42. Reply only with: OK'
OK

$ claude --continue
No conversation found to continue        # ← BUG: the session clearly exists

$ claude -p --continue "What did I ask earlier?"
42                                        # ← headless continue works fine

$ CLAUDE_CODE_ENTRYPOINT=sdk-cli claude --continue
# ← interactive UI opens normally, with the -p session history fully loaded

The contrast between steps 2 and 3 is the whole story: the same session data continues fine in headless mode but is "not found" in interactive mode. The session file sits happily in ~/.claude/projects/<project-path>/ as a .jsonl — we checked, and sessions created by -p live in the same place, in the same format, as interactive ones.

The trap: a filter applied one command too far

This is a regression introduced in v2.1.90. That release's changelog says: "Changed --resume picker to no longer show sessions created by claude -p or SDK invocations" — a reasonable product decision on its own (a picker full of one-shot scripted sessions is noisy).

The problem: that filter was also applied to --continue, whose semantics — continue the latest session — should not care how the session was created. So:

  • The most recent (or only) session in the directory was created by -p → interactive --continue filters it out → No conversation found to continue
  • The headless path -p --continue was fixed after an earlier issue (#43013) → works all along
  • The data layer is intact: session metadata, entrypoint fields, and jsonl content are all fine

The GitHub issue (#82536, reported on Fedora + tmux) and our macOS reproduction confirm each other — this is a cross-platform logic bug, not an environment quirk, present from v2.1.90 through v2.1.220 and counting.

Two verified workarounds

1. Just need one follow-up question → headless continue (simplest)

claude -p --continue "Following up on that result, check X for me"

2. Need to take over interactively → prefix the environment variable

CLAUDE_CODE_ENTRYPOINT=sdk-cli claude --continue

The variable makes the CLI start as an SDK entrypoint, which bypasses the interactive session filter. In our test the interactive UI opened normally with full history loaded, and everything behaved like a regular session afterwards. Credit for discovering this goes to the issue author; we verified it works on macOS.

One debugging trap to know: if you run claude --continue through a pipe or redirect (stdout is not a TTY), the error message changes to No deferred tool marker found in the resumed session — the same bug wearing a different mask. Do not let it send you off hunting for "tool markers".

Scope and boundaries

  • Affects every version since v2.1.90 (tested here on v2.1.220, same version as the issue report; unfixed with no linked PR at the time of writing)
  • Only interactive --continue/--resume discovery of -p/SDK sessions is affected; headless -p --continue is fine
  • Reproduced on both macOS and Fedora; model-independent
  • Inferred from the filtering mechanism (not separately tested): when a directory holds both an interactive session and a newer -p session, interactive --continue will skip the -p session and silently pick up the older interactive one — no error, but not the "latest" session you meant, which is sneakier than failing outright
📚 Browse all Claude tutorials →

Related Articles

Which Model Is Claude Code Actually Using? settings.json vs ANTHROPIC_MODEL vs --model, Tested

Multi-agent setups, CI, and batch scripts all rest on one assumption: the session actually runs on the model you configured. But the model can be set in four places — settings.json, the ANTHROPIC_MODEL environment variable, the --model flag, and /model in-session — and the docs never give you one table saying which wins. Meanwhile a GitHub issue reports settings.json silently ignored on Windows, with a full day of work run on the wrong model and discarded. Using modelUsage as hard evidence, we tested the chain layer by layer: --model > ANTHROPIC_MODEL > project settings.json > built-in default, with the [1m] suffix form working too — plus a verification method more trustworthy than any UI hint.

claude-codeclaude-code-lab+4
claudeAug 6, 20263 min
2

The Claude Code Hooks Stdin Trap: Python Heredocs Eat Your Hook JSON

The docs say hooks receive JSON via stdin — true. But parse it with a python heredoc (python3 - <<'EOF') and you hit a silent failure: the heredoc redirects python's stdin to the script itself, so json.load(sys.stdin) reads nothing. A best-practice hook then swallows the exception and exits 0 — no error anywhere, just a hook that 'somehow does not work'. The real debugging session, the two-line fix, and a lesson: silently fault-tolerant code is your enemy at debugging time.

claude-codehooks+5
claudeAug 6, 20263 min
20

I Put My Opus 5 Config on the Recommended Diet, Then Ran 18 A/B Trials: 21% Cheaper, and I Can't Prove It's Better

"Opus 5 verifies itself, so delete your fallback prompts" is advice you hear everywhere. I took it, then isolated both configs with CLAUDE_CONFIG_DIR and ran 18 headless trials on identical tasks. Output tokens dropped 21% and wall clock 20-29%, with zero counterexamples. But two of the rewritten rules never fired at all, and one result points the other way: the old config's most thorough run covered a strict superset of what the new one found. Why cheaper and better are separate questions.

prompt-engineeringclaude-code+4
claudeAug 5, 20266 min
36

Half My openclaw Commands Ran, Half Didn't — It Looked Like a Permission Classifier, It Was launchd

Same machine, same user, same global config. Two Claude Code windows running the same CLI — one worked, one didn't. The obvious suspect was the permission classifier, which really does block commands. But the cause sat a layer down: the daemon's plist was installed and never loaded, so every gateway-bound subcommand died while purely local ones printed fine. That half-working shape is what sells the permission theory. Full trace, including the hypothesis I got wrong by misreading my own logs.

permissionstroubleshooting+4
developerAug 4, 20267 min
48

Try these free online tools

JSON FormatterFormat, minify, and validate JSON. Supports drag-and-drop upload, live preview, and error hints.JS / CSS FormatterFormat and minify JavaScript, CSS, and HTML code online. Beautify or compress for production. 100% local.Diff CheckerCompare two texts line by line. Highlights additions and deletions. Unified and split view.Schema Markup GeneratorGenerate JSON-LD structured data for Google rich results. Supports Article, FAQ, Product, LocalBusiness, and more.Regex TesterTest regular expressions in real time with match highlighting, group details, and flag controls.Word CounterCount words, characters, sentences, paragraphs and estimate reading time. Real-time, works offline.

Published by MagicTools