perf: keep the send path off the main thread's disk and git

[Tryanks]

Problem

Sending a follow-up message stalled the whole UI for seconds — tens of seconds on a nearly-full disk — because dispatch_next_queued did three pieces of heavy synchronous I/O on the UI thread before the turn could start:

1. event_count() read AND parsed the entire session JSONL just to count events — tens of MB for a long conversation, on every send.
2. capture_checkpoint() ran six blocking git subprocesses (read-tree, add -A over the whole worktree, write-tree, commit-tree, update-ref), no timeout.
3. persist_meta() reloaded and re-parsed the whole sessions.json index after every upsert.

Checkpoint refs also accumulated forever (one repo: 153 refs / 1.18 GiB of loose objects), themselves contributing to the disk pressure that made the stalls so bad.

Fix

• event_count() is now a newline byte-scan — append_event writes exactly one \n-terminated line per event, so the count is identical. (A crash-corrupted line can make a revert boundary sit slightly deep, never over-truncate.)
• The checkpoint capture runs on the background executor via blocking::unblock. Two new flags preserve semantics: recorded_undispatched (head recorded but not yet sent — no double-record on re-entry) and awaiting_checkpoint (dispatch held until the capture lands, so the snapshot still precedes any agent edits). Rewind, session parking, queue-strip drops, and provider death during a capture are all handled; a capture landing after a rewind drops its stale result.
• persist_meta reflects the upsert in memory (kept newest-first) instead of reloading the index from disk.
• Checkpoints are capped at 20 per session; older refs are deleted off-thread and their turns lose the Revert affordance.

The user message bubble still appears synchronously on send; only the turn start waits for the snapshot (typically milliseconds).

Tests

• New: checkpoints_are_capped_and_old_refs_pruned.
• Adjusted three tests that assumed send→dispatch was synchronous (the bubble is still synchronous; only the turn command now waits for the capture).
• cargo test --workspace green, cargo clippy --workspace --all-targets clean.

🤖 Generated with Claude Code

[Tryanks]

Problem

Sending a follow-up message stalled the whole UI for seconds — tens of seconds on a nearly-full disk — because dispatch_next_queued did three pieces of heavy synchronous I/O on the UI thread before the turn could start:

1. event_count() read AND parsed the entire session JSONL just to count events — tens of MB for a long conversation, on every send.
2. capture_checkpoint() ran six blocking git subprocesses (read-tree, add -A over the whole worktree, write-tree, commit-tree, update-ref), no timeout.
3. persist_meta() reloaded and re-parsed the whole sessions.json index after every upsert.

Checkpoint refs also accumulated forever (one repo: 153 refs / 1.18 GiB of loose objects), themselves contributing to the disk pressure that made the stalls so bad.

Fix

• event_count() is now a newline byte-scan — append_event writes exactly one \n-terminated line per event, so the count is identical. (A crash-corrupted line can make a revert boundary sit slightly deep, never over-truncate.)
• The checkpoint capture runs on the background executor via blocking::unblock. Two new flags preserve semantics: recorded_undispatched (head recorded but not yet sent — no double-record on re-entry) and awaiting_checkpoint (dispatch held until the capture lands, so the snapshot still precedes any agent edits). Rewind, session parking, queue-strip drops, and provider death during a capture are all handled; a capture landing after a rewind drops its stale result.
• persist_meta reflects the upsert in memory (kept newest-first) instead of reloading the index from disk.
• Checkpoints are capped at 20 per session; older refs are deleted off-thread and their turns lose the Revert affordance.

The user message bubble still appears synchronously on send; only the turn start waits for the snapshot (typically milliseconds).

Tests

• New: checkpoints_are_capped_and_old_refs_pruned.
• Adjusted three tests that assumed send→dispatch was synchronous (the bubble is still synchronous; only the turn command now waits for the capture).
• cargo test --workspace green, cargo clippy --workspace --all-targets clean.

🤖 Generated with Claude Code

[Tryanks]

Problem

Sending a follow-up message stalled the whole UI for seconds — tens of seconds on a nearly-full disk — because dispatch_next_queued did three pieces of heavy synchronous I/O on the UI thread before the turn could start:

1. event_count() read AND parsed the entire session JSONL just to count events — tens of MB for a long conversation, on every send.
2. capture_checkpoint() ran six blocking git subprocesses (read-tree, add -A over the whole worktree, write-tree, commit-tree, update-ref), no timeout.
3. persist_meta() reloaded and re-parsed the whole sessions.json index after every upsert.

Checkpoint refs also accumulated forever (one repo: 153 refs / 1.18 GiB of loose objects), themselves contributing to the disk pressure that made the stalls so bad.

Fix

• event_count() is now a newline byte-scan — append_event writes exactly one \n-terminated line per event, so the count is identical. (A crash-corrupted line can make a revert boundary sit slightly deep, never over-truncate.)
• The checkpoint capture runs on the background executor via blocking::unblock. Two new flags preserve semantics: recorded_undispatched (head recorded but not yet sent — no double-record on re-entry) and awaiting_checkpoint (dispatch held until the capture lands, so the snapshot still precedes any agent edits). Rewind, session parking, queue-strip drops, and provider death during a capture are all handled; a capture landing after a rewind drops its stale result.
• persist_meta reflects the upsert in memory (kept newest-first) instead of reloading the index from disk.
• Checkpoints are capped at 20 per session; older refs are deleted off-thread and their turns lose the Revert affordance.

The user message bubble still appears synchronously on send; only the turn start waits for the snapshot (typically milliseconds).

Tests

• New: checkpoints_are_capped_and_old_refs_pruned.
• Adjusted three tests that assumed send→dispatch was synchronous (the bubble is still synchronous; only the turn command now waits for the capture).
• cargo test --workspace green, cargo clippy --workspace --all-targets clean.

🤖 Generated with Claude Code

[Tryanks]

Problem

Sending a follow-up message stalled the whole UI for seconds — tens of seconds on a nearly-full disk — because dispatch_next_queued did three pieces of heavy synchronous I/O on the UI thread before the turn could start:

1. event_count() read AND parsed the entire session JSONL just to count events — tens of MB for a long conversation, on every send.
2. capture_checkpoint() ran six blocking git subprocesses (read-tree, add -A over the whole worktree, write-tree, commit-tree, update-ref), no timeout.
3. persist_meta() reloaded and re-parsed the whole sessions.json index after every upsert.

Checkpoint refs also accumulated forever (one repo: 153 refs / 1.18 GiB of loose objects), themselves contributing to the disk pressure that made the stalls so bad.

Fix

• event_count() is now a newline byte-scan — append_event writes exactly one \n-terminated line per event, so the count is identical. (A crash-corrupted line can make a revert boundary sit slightly deep, never over-truncate.)
• The checkpoint capture runs on the background executor via blocking::unblock. Two new flags preserve semantics: recorded_undispatched (head recorded but not yet sent — no double-record on re-entry) and awaiting_checkpoint (dispatch held until the capture lands, so the snapshot still precedes any agent edits). Rewind, session parking, queue-strip drops, and provider death during a capture are all handled; a capture landing after a rewind drops its stale result.
• persist_meta reflects the upsert in memory (kept newest-first) instead of reloading the index from disk.
• Checkpoints are capped at 20 per session; older refs are deleted off-thread and their turns lose the Revert affordance.

The user message bubble still appears synchronously on send; only the turn start waits for the snapshot (typically milliseconds).

Tests

• New: checkpoints_are_capped_and_old_refs_pruned.
• Adjusted three tests that assumed send→dispatch was synchronous (the bubble is still synchronous; only the turn command now waits for the capture).
• cargo test --workspace green, cargo clippy --workspace --all-targets clean.

🤖 Generated with Claude Code

[Tryanks]

Problem

Sending a follow-up message stalled the whole UI for seconds — tens of seconds on a nearly-full disk — because dispatch_next_queued did three pieces of heavy synchronous I/O on the UI thread before the turn could start:

1. event_count() read AND parsed the entire session JSONL just to count events — tens of MB for a long conversation, on every send.
2. capture_checkpoint() ran six blocking git subprocesses (read-tree, add -A over the whole worktree, write-tree, commit-tree, update-ref), no timeout.
3. persist_meta() reloaded and re-parsed the whole sessions.json index after every upsert.

Checkpoint refs also accumulated forever (one repo: 153 refs / 1.18 GiB of loose objects), themselves contributing to the disk pressure that made the stalls so bad.

Fix

• event_count() is now a newline byte-scan — append_event writes exactly one \n-terminated line per event, so the count is identical. (A crash-corrupted line can make a revert boundary sit slightly deep, never over-truncate.)
• The checkpoint capture runs on the background executor via blocking::unblock. Two new flags preserve semantics: recorded_undispatched (head recorded but not yet sent — no double-record on re-entry) and awaiting_checkpoint (dispatch held until the capture lands, so the snapshot still precedes any agent edits). Rewind, session parking, queue-strip drops, and provider death during a capture are all handled; a capture landing after a rewind drops its stale result.
• persist_meta reflects the upsert in memory (kept newest-first) instead of reloading the index from disk.
• Checkpoints are capped at 20 per session; older refs are deleted off-thread and their turns lose the Revert affordance.

The user message bubble still appears synchronously on send; only the turn start waits for the snapshot (typically milliseconds).

Tests

• New: checkpoints_are_capped_and_old_refs_pruned.
• Adjusted three tests that assumed send→dispatch was synchronous (the bubble is still synchronous; only the turn command now waits for the capture).
• cargo test --workspace green, cargo clippy --workspace --all-targets clean.

🤖 Generated with Claude Code

[Tryanks]

Problem

Sending a follow-up message stalled the whole UI for seconds — tens of seconds on a nearly-full disk — because dispatch_next_queued did three pieces of heavy synchronous I/O on the UI thread before the turn could start:

1. event_count() read AND parsed the entire session JSONL just to count events — tens of MB for a long conversation, on every send.
2. capture_checkpoint() ran six blocking git subprocesses (read-tree, add -A over the whole worktree, write-tree, commit-tree, update-ref), no timeout.
3. persist_meta() reloaded and re-parsed the whole sessions.json index after every upsert.

Checkpoint refs also accumulated forever (one repo: 153 refs / 1.18 GiB of loose objects), themselves contributing to the disk pressure that made the stalls so bad.

Fix

• event_count() is now a newline byte-scan — append_event writes exactly one \n-terminated line per event, so the count is identical. (A crash-corrupted line can make a revert boundary sit slightly deep, never over-truncate.)
• The checkpoint capture runs on the background executor via blocking::unblock. Two new flags preserve semantics: recorded_undispatched (head recorded but not yet sent — no double-record on re-entry) and awaiting_checkpoint (dispatch held until the capture lands, so the snapshot still precedes any agent edits). Rewind, session parking, queue-strip drops, and provider death during a capture are all handled; a capture landing after a rewind drops its stale result.
• persist_meta reflects the upsert in memory (kept newest-first) instead of reloading the index from disk.
• Checkpoints are capped at 20 per session; older refs are deleted off-thread and their turns lose the Revert affordance.

The user message bubble still appears synchronously on send; only the turn start waits for the snapshot (typically milliseconds).

Tests

• New: checkpoints_are_capped_and_old_refs_pruned.
• Adjusted three tests that assumed send→dispatch was synchronous (the bubble is still synchronous; only the turn command now waits for the capture).
• cargo test --workspace green, cargo clippy --workspace --all-targets clean.

🤖 Generated with Claude Code

[Tryanks]

Problem

Sending a follow-up message stalled the whole UI for seconds — tens of seconds on a nearly-full disk — because dispatch_next_queued did three pieces of heavy synchronous I/O on the UI thread before the turn could start:

1. event_count() read AND parsed the entire session JSONL just to count events — tens of MB for a long conversation, on every send.
2. capture_checkpoint() ran six blocking git subprocesses (read-tree, add -A over the whole worktree, write-tree, commit-tree, update-ref), no timeout.
3. persist_meta() reloaded and re-parsed the whole sessions.json index after every upsert.

Checkpoint refs also accumulated forever (one repo: 153 refs / 1.18 GiB of loose objects), themselves contributing to the disk pressure that made the stalls so bad.

Fix

• event_count() is now a newline byte-scan — append_event writes exactly one \n-terminated line per event, so the count is identical. (A crash-corrupted line can make a revert boundary sit slightly deep, never over-truncate.)
• The checkpoint capture runs on the background executor via blocking::unblock. Two new flags preserve semantics: recorded_undispatched (head recorded but not yet sent — no double-record on re-entry) and awaiting_checkpoint (dispatch held until the capture lands, so the snapshot still precedes any agent edits). Rewind, session parking, queue-strip drops, and provider death during a capture are all handled; a capture landing after a rewind drops its stale result.
• persist_meta reflects the upsert in memory (kept newest-first) instead of reloading the index from disk.
• Checkpoints are capped at 20 per session; older refs are deleted off-thread and their turns lose the Revert affordance.

The user message bubble still appears synchronously on send; only the turn start waits for the snapshot (typically milliseconds).

Tests

• New: checkpoints_are_capped_and_old_refs_pruned.
• Adjusted three tests that assumed send→dispatch was synchronous (the bubble is still synchronous; only the turn command now waits for the capture).
• cargo test --workspace green, cargo clippy --workspace --all-targets clean.

🤖 Generated with Claude Code

[Tryanks]

Problem

Sending a follow-up message stalled the whole UI for seconds — tens of seconds on a nearly-full disk — because dispatch_next_queued did three pieces of heavy synchronous I/O on the UI thread before the turn could start:

1. event_count() read AND parsed the entire session JSONL just to count events — tens of MB for a long conversation, on every send.
2. capture_checkpoint() ran six blocking git subprocesses (read-tree, add -A over the whole worktree, write-tree, commit-tree, update-ref), no timeout.
3. persist_meta() reloaded and re-parsed the whole sessions.json index after every upsert.

Checkpoint refs also accumulated forever (one repo: 153 refs / 1.18 GiB of loose objects), themselves contributing to the disk pressure that made the stalls so bad.

Fix

• event_count() is now a newline byte-scan — append_event writes exactly one \n-terminated line per event, so the count is identical. (A crash-corrupted line can make a revert boundary sit slightly deep, never over-truncate.)
• The checkpoint capture runs on the background executor via blocking::unblock. Two new flags preserve semantics: recorded_undispatched (head recorded but not yet sent — no double-record on re-entry) and awaiting_checkpoint (dispatch held until the capture lands, so the snapshot still precedes any agent edits). Rewind, session parking, queue-strip drops, and provider death during a capture are all handled; a capture landing after a rewind drops its stale result.
• persist_meta reflects the upsert in memory (kept newest-first) instead of reloading the index from disk.
• Checkpoints are capped at 20 per session; older refs are deleted off-thread and their turns lose the Revert affordance.

The user message bubble still appears synchronously on send; only the turn start waits for the snapshot (typically milliseconds).

Tests

• New: checkpoints_are_capped_and_old_refs_pruned.
• Adjusted three tests that assumed send→dispatch was synchronous (the bubble is still synchronous; only the turn command now waits for the capture).
• cargo test --workspace green, cargo clippy --workspace --all-targets clean.

🤖 Generated with Claude Code