[PR #37] [MERGED] fix: Session-agnostic catchup scanning across all sessions #64

New issue

Closed

opened 2026-03-03 18:50:23 +03:00 by kerem · 0 comments

kerem commented

2026-03-03 18:50:23 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/OthmanAdi/planning-with-files/pull/37
Author: @lasmarois
Created: 1/17/2026
Status: ✅ Merged
Merged: 1/17/2026
Merged by: @OthmanAdi

Base: master ← Head: fix/session-catchup-exclude-current

📝 Commits (1)

dcba1bc fix: Session-agnostic catchup scanning across all sessions

📊 Changes

1 file changed (+185 additions, -115 deletions)

View changed files

📝 scripts/session-catchup.py (+185 -115)

📄 Description

Problem

The first iteration of session-catchup.py had two issues:

Issue 1: Picked the current session instead of previous

The script sorted sessions by modification time and picked the first "substantial" one (>5000 bytes). But the current session is always the most recently modified, so it would detect itself as the "previous" session—showing the current session's own context as "unsynced."

Issue 2: Only looked at one session

Even after fixing issue 1 by skipping the first session, the script only examined the single session containing the last planning file update. This missed important context from intermediate sessions.

Example of the problem:

Session A: Last planning file update (progress.md edited)
Session B: Continued work, discussed audit logs redesign ← MISSED!
Session C: More work, asked user questions ← MISSED!
Session D: Current session

The old script would only show context from Session A after the planning update, completely missing Sessions B and C.

Solution

Rewrote the script to be session-agnostic:

Skip current session (index 0, most recently modified)
Scan all previous sessions newest→oldest to find the most recent planning file update
Collect ALL messages from that point forward, across ALL sessions until current
Show session markers [Session: xxx...] when context spans multiple sessions
Display up to 100 messages with truncation notice if exceeded

Why 100 messages?

The original limit of 20 messages was too restrictive—newer sessions would push older (but important) context out of view entirely. However, unlimited output creates edge case risks:

Context bloat: If planning files haven't been updated in weeks, hundreds of messages could flood the output
Output truncation: Claude Code may truncate very long tool outputs
Noise vs signal: Very old messages become less relevant

100 messages strikes a balance—enough to capture multi-session context while avoiding edge case blowups. If truncated, the script shows: (Showing last 100 of X messages)

Example of the fix:

[planning-with-files] SESSION CATCHUP DETECTED
Last planning update: progress.md in session b83a493f...
Scanning 7 sessions for unsynced context
Unsynced messages: 73

--- UNSYNCED CONTEXT ---

[Session: b83a493f...]
USER: archive the files, add new subm for audit logs revamp...
CLAUDE: Done! M9.8.39 - Audit Logs Revamp added...

[Session: 4a3b300c...]
CLAUDE: M9.8.39 - Audit Logs Revamp is next. Let me ask what you have in mind.
  Tools: AskUserQuestion
CLAUDE: A visual redesign. Let me look at the current UI...

[Session: d0d7e46c...]
CLAUDE: Continuing from previous session...

Note

@OthmanAdi Apologies for the confusion during testing of the first iteration—the "detecting itself" bug made it tricky to verify the fix was actually working, since the output looked plausible but was pulling from the wrong session. This rewrite was validated by tracing through actual session files to confirm the correct sessions and messages are being captured.

Changes

scripts/session-catchup.py: Complete rewrite with session-agnostic scanning

Test Plan

Run /planning-with-files after /clear - should show context from all sessions since last planning update
Verify current session is never picked as "previous"
Confirm intermediate sessions (without planning updates) are included
Check session markers appear when context spans multiple sessions

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/OthmanAdi/planning-with-files/pull/37 **Author:** [@lasmarois](https://github.com/lasmarois) **Created:** 1/17/2026 **Status:** ✅ Merged **Merged:** 1/17/2026 **Merged by:** [@OthmanAdi](https://github.com/OthmanAdi) **Base:** `master` ← **Head:** `fix/session-catchup-exclude-current` --- ### 📝 Commits (1) - [`dcba1bc`](https://github.com/OthmanAdi/planning-with-files/commit/dcba1bc92cd11c7c5f2e061d2736b77d94f746b5) fix: Session-agnostic catchup scanning across all sessions ### 📊 Changes **1 file changed** (+185 additions, -115 deletions) <details> <summary>View changed files</summary> 📝 `scripts/session-catchup.py` (+185 -115) </details> ### 📄 Description ## Problem The first iteration of `session-catchup.py` had two issues: ### Issue 1: Picked the current session instead of previous The script sorted sessions by modification time and picked the first "substantial" one (>5000 bytes). But the current session is always the most recently modified, so it would detect itself as the "previous" session—showing the current session's own context as "unsynced." ### Issue 2: Only looked at one session Even after fixing issue 1 by skipping the first session, the script only examined the single session containing the last planning file update. This missed important context from intermediate sessions. **Example of the problem:** ``` Session A: Last planning file update (progress.md edited) Session B: Continued work, discussed audit logs redesign ← MISSED! Session C: More work, asked user questions ← MISSED! Session D: Current session ``` The old script would only show context from Session A after the planning update, completely missing Sessions B and C. ## Solution Rewrote the script to be **session-agnostic**: 1. **Skip current session** (index 0, most recently modified) 2. **Scan all previous sessions** newest→oldest to find the most recent planning file update 3. **Collect ALL messages** from that point forward, across ALL sessions until current 4. **Show session markers** `[Session: xxx...]` when context spans multiple sessions 5. **Display up to 100 messages** with truncation notice if exceeded ### Why 100 messages? The original limit of 20 messages was too restrictive—newer sessions would push older (but important) context out of view entirely. However, unlimited output creates edge case risks: - **Context bloat**: If planning files haven't been updated in weeks, hundreds of messages could flood the output - **Output truncation**: Claude Code may truncate very long tool outputs - **Noise vs signal**: Very old messages become less relevant 100 messages strikes a balance—enough to capture multi-session context while avoiding edge case blowups. If truncated, the script shows: `(Showing last 100 of X messages)` **Example of the fix:** ``` [planning-with-files] SESSION CATCHUP DETECTED Last planning update: progress.md in session b83a493f... Scanning 7 sessions for unsynced context Unsynced messages: 73 --- UNSYNCED CONTEXT --- [Session: b83a493f...] USER: archive the files, add new subm for audit logs revamp... CLAUDE: Done! M9.8.39 - Audit Logs Revamp added... [Session: 4a3b300c...] CLAUDE: M9.8.39 - Audit Logs Revamp is next. Let me ask what you have in mind. Tools: AskUserQuestion CLAUDE: A visual redesign. Let me look at the current UI... [Session: d0d7e46c...] CLAUDE: Continuing from previous session... ``` ## Note @OthmanAdi Apologies for the confusion during testing of the first iteration—the "detecting itself" bug made it tricky to verify the fix was actually working, since the output looked plausible but was pulling from the wrong session. This rewrite was validated by tracing through actual session files to confirm the correct sessions and messages are being captured. ## Changes - `scripts/session-catchup.py`: Complete rewrite with session-agnostic scanning ## Test Plan - [x] Run `/planning-with-files` after `/clear` - should show context from all sessions since last planning update - [x] Verify current session is never picked as "previous" - [x] Confirm intermediate sessions (without planning updates) are included - [x] Check session markers appear when context spans multiple sessions --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>