Session Display Issue: 'Warming Up' Messages and Safe Metadata Architecture

[nofluffsev]

Last login: Wed Oct 22 08:50:11 on ttys000

Session Display Issue: "Warming Up" Messages and Architectural Concerns

Summary

Opcode currently displays "Warmup" as the session name for many sessions, which is the cache-warming initialization message Claude Code sends. This issue proposes an architectural solution that avoids mutating immutable session files.

Current Behavior

When Claude Code starts a session, it sends a "Warmup" message to initialize prompt caching. Opcode reads the first message from the .jsonl file and displays "Warmup" as the session name, which is not useful for users trying to distinguish between sessions.

Problem Analysis

The root issue is that Opcode treats the first line of .jsonl files as display metadata, when these files are actually immutable append-only event logs.

Why This Matters

Claude Code's session files follow an append-only log structure with parent-child UUID chains:

{"parentUuid": null, "uuid": "uuid-1", "type": "user", "message": {"content": "Warmup"}, ...}
{"parentUuid": "uuid-1", "uuid": "uuid-2", "type": "assistant", ...}
{"parentUuid": "uuid-2", "uuid": "uuid-3", "type": "user", "message": {"content": "Real task"}, ...}

Modifying line 1 after it's written breaks the conversation state chain and can corrupt active sessions. In testing, modifying .jsonl files while Claude Code is running caused:

1. Orphaned tool_result blocks (missing corresponding tool_use)
2. API validation errors (400: invalid_request_error)
3. Permanently broken sessions requiring full restarts

Race Condition Evidence

When a script modifies line 1 of an active session file:

• Claude Code maintains in-memory conversation state based on the original file
• File modification breaks parent UUID chains
• Subsequent appends reference deleted messages
• API rejects malformed conversation structure

Example error from testing:

API Error: 400 {"type":"error","error":{"type":"invalid_request_error",
"message":"messages.0.content.0: unexpected `tool_use_id` found in `tool_result` blocks:
toolu_0137Wrese1mAxmVb7CPSsFJT. Each `tool_result` block must have a corresponding
`tool_use` block in the previous message."}}

[westar9800]

Last login: Wed Oct 22 08:50:11 on ttys000

Session Display Issue: "Warming Up" Messages and Architectural Concerns

Summary

Opcode currently displays "Warmup" as the session name for many sessions, which is the cache-warming initialization message Claude Code sends. This issue proposes an architectural solution that avoids mutating immutable session files.

Current Behavior

When Claude Code starts a session, it sends a "Warmup" message to initialize prompt caching. Opcode reads the first message from the .jsonl file and displays "Warmup" as the session name, which is not useful for users trying to distinguish between sessions.

Problem Analysis

The root issue is that Opcode treats the first line of .jsonl files as display metadata, when these files are actually immutable append-only event logs.

Why This Matters

Claude Code's session files follow an append-only log structure with parent-child UUID chains:

{"parentUuid": null, "uuid": "uuid-1", "type": "user", "message": {"content": "Warmup"}, ...}
{"parentUuid": "uuid-1", "uuid": "uuid-2", "type": "assistant", ...}
{"parentUuid": "uuid-2", "uuid": "uuid-3", "type": "user", "message": {"content": "Real task"}, ...}

Modifying line 1 after it's written breaks the conversation state chain and can corrupt active sessions. In testing, modifying .jsonl files while Claude Code is running caused:

1. Orphaned tool_result blocks (missing corresponding tool_use)
2. API validation errors (400: invalid_request_error)
3. Permanently broken sessions requiring full restarts

Race Condition Evidence

When a script modifies line 1 of an active session file:

• Claude Code maintains in-memory conversation state based on the original file
• File modification breaks parent UUID chains
• Subsequent appends reference deleted messages
• API rejects malformed conversation structure

Example error from testing:

API Error: 400 {"type":"error","error":{"type":"invalid_request_error",
"message":"messages.0.content.0: unexpected `tool_use_id` found in `tool_result` blocks:
toolu_0137Wrese1mAxmVb7CPSsFJT. Each `tool_result` block must have a corresponding
`tool_use` block in the previous message."}}