Feature request

Qwen Code already has session resume support (--continue, --resume, and the interactive /resume picker), but there is currently no user-facing way to branch/fork from an existing session into a new session ID.

This would be useful when a user wants to explore an alternative direction from a previous conversation without mutating or appending to the original session history.

Current behavior

Today, users can:

• qwen --continue to resume the most recent session for the current project.
• qwen --resume <session-id> to resume a specific session.
• Use /resume in interactive mode to select a previous session.
• Use --session-id <uuid> to start a new session with a specific ID.

However, resuming a session continues with the same session identity/history. There is no CLI or picker affordance for:

qwen --resume <session-id> --fork-session
qwen --continue --fork-session

or an equivalent action in the /resume picker.

Proposed behavior

Add a --fork-session option that is only valid together with --resume or --continue.

Suggested semantics:

1. Resolve the source session using the existing --resume / --continue logic.
2. Create a new session ID.
3. Copy the source conversation into the new session as a fork/branch.
4. Continue execution using the new session ID.
5. Preserve metadata that lets users/tools know the new session was forked from the source session.

Example UX:

qwen --resume 123e4567-e89b-12d3-a456-426614174000 --fork-session
# Forked session 123e4567-e89b-12d3-a456-426614174000 -> <new-session-id>

For interactive mode, the /resume picker could also expose a secondary action such as “fork/branch from this session” in addition to normal resume.

Why this matters

This avoids accidental modification of an existing session when users want to:

• Try a different implementation approach from a previous context.
• Keep the original session as an audit trail.
• Compare multiple solution paths from the same starting point.
• Resume a known-good context while preserving the ability to return to the original line of work.

Notes

There appears to already be a core-level primitive for this kind of operation (SessionService.forkSession(...)). The main missing pieces seem to be CLI validation, integration with --resume / --continue, and interactive picker UX.

Potential validation rules:

• --fork-session without --resume or --continue should fail with a clear error.
• --fork-session should not be allowed with --session-id unless a specific semantics is intentionally designed.
• If the target generated session ID collides, retry or fail safely.
• Forked sessions should preserve enough parent/source metadata for debugging and export flows.

Suggested tests

• qwen --resume <id> --fork-session creates and resumes a new session ID.
• qwen --continue --fork-session forks the latest session for the current project.
• Invalid flag combinations produce clear errors.
• Forked session history can be loaded by --resume <new-id>.
• Existing resume history, compression checkpoints, and rewind/turn-boundary behavior remain correct after forking.