Skip to content

[BUG] [v0.0.7] handle_fork_session() does not record pre-fork messages to new rollout file - forked session loses conversation history on resume (handlers.rs:546-561) #53462

Description

@andrirevo

Project

cortex

Description

Forking a session in-session is supposed to preserve a chosen prefix of the conversation while creating a new session identity. The in-memory session may look correct immediately after fork, but the new rollout file records session metadata without writing the retained user/assistant messages as events. On later resume, the client loads a rollout that effectively contains only meta, so pre-fork history disappears even though it existed in memory at fork time. This diverges from the Session::fork path which does record copied events, creating inconsistent persistence semantics between fork mechanisms.

Error Message

Debug Logs

System Information

macOS / 0.0.7

Screenshots

https://github.com/springoliver/bounty_challenge_report_image/blob/main/49107.png

Steps to Reproduce

  1. Open the affected cortex command or screen.
  2. Execute the exact input pattern named in this issue title and narrative.
  3. Compare actual output against the expected contract documented by the reporter.

Expected Behavior

The reporter expects cortex to match documented CLI/TUI contracts for this flow—correct output, honest flags/help, and no silent contradictions—consistent with the problem statement at the top of this rewrite.

Actual Behavior

Forking a session in-session is supposed to preserve a chosen prefix of the conversation while creating a new session identity. The in-memory session may look correct immediately after fork, but the new rollout file records session metadata without writing the retained user/assistant messages as events. On later resume, the client loads a rollout that effectively contains only meta, so pre-fork history disappears even though it existed in memory at fork time. This diverges from the Session::fork path which does record copied events, creating inconsistent persistence semantics between fork mechanisms.

Additional Context

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workinginvalidThis doesn't seem right

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions