What causes "failed to continue {} session {} for {}" in nikivdev/code?

Re-run the continue command to surface the provider CLI's own error output

failed to continue {} session {} for {}

Error message

failed to continue {} session {} for {}

What it means

When a specific session's resume command is dispatched but the provider CLI exits without successfully continuing that session, src/ai.rs:5481 bails with the provider name, session id, and target path in the message. This indicates the launch attempt for that exact session record failed, not a missing session file.

Source

Thrown at src/ai.rs:5481

                target.display()
            )
        })?;
        println!(
            "Resuming session {} from {}...",
            &sess.session_id[..8.min(sess.session_id.len())],
            target.display()
        );
        if launch_session_for_target(
            &sess.session_id,
            sess.provider,
            None,
            Some(&target),
            None,
            None,
        )? {
            return Ok(());
        }
        bail!(
            "failed to continue {} session {} for {}",
            provider_name(sess.provider),
            sess.session_id,
            target.display()
        );
    }

    let launched = match provider {
        Provider::Claude => launch_claude_continue()?,
        Provider::Codex => launch_codex_continue_last_for_target(None, false)?,
        Provider::Cursor => false,
        Provider::All => false,
    };

    if launched {
        Ok(())
    } else {
        bail!("failed to continue {} session", provider_name(provider))

View on GitHub (pinned to a747e741ae)

Solutions

Re-run the continue command to surface the provider CLI's own error output
Verify the session id still exists in the provider's native session store (~/.claude/projects, ~/.codex/sessions)
Re-authenticate the provider CLI (claude login / codex auth) and retry
Delete or ignore the stale session and start a new one (`f ai <provider> continue` without id creates new)

Example fix

// before: stale session id from an old provider version
$ f ai codex continue --session abc123-old-format
// after: let it resume the latest or start fresh
$ f ai codex continue

Defensive patterns

Strategy: fallback

Validate before calling

if !provider_session_exists(target, &session_id) {
    eprintln!("Session {} not found for {}; starting a new one instead.", session_id, target.display());
    return continue_session(provider, None, Some(target));
}

Type guard

fn is_resume_failure(msg: &str) -> bool {
    msg.starts_with("failed to continue")
}

Try / catch

match resume_session(session, path, provider) {
    Err(e) if e.to_string().starts_with("failed to continue") => {
        eprintln!("{e} — falling back to launching a new session");
        let _ = continue_session(provider, None, path);
    }
    other => other?,
}

Prevention

Re-authenticate the provider CLI so launches don't exit early
Drop stale session ids after provider upgrades (session storage formats change)
Verify the session id exists in the provider's native store before resuming
Keep the project target path stable — session records are keyed to it

When it happens

Trigger: resume_session for an existing session record (sess.provider, sess.session_id, target) whose launch path returns without success — provider CLI exited non-zero, session id no longer valid on disk, or the provider binary refused the flags used to continue it.

Common situations: Session file exists in the target dir but the provider CLI deleted/expired that session id (version upgrade changing session storage); provider CLI not authenticated so it exits immediately; corrupted session transcript rejected by the CLI.

Related errors

AI-assisted analysis of nikivdev/code@a747e741ae (2026-09-01). Data as JSON: /api/errors/69a3cab83c910e8c. Report an issue: GitHub.