Session status dot stuck on purple after network interruption

[grimmerk]

Problem

An active Claude Code session shows a purple dot (unknown status) instead of the expected green dot (idle) in the Sessions tab. The purple dot persists permanently — refreshing, switching tabs, and re-focusing the window don't fix it.

A separate symptom was also observed: the dot occasionally disappeared entirely (session not detected as active), even though the Claude process was still running. This symptom was not reproduced after adding debug logging, so its cause remains unknown. It may or may not be related to the purple dot issue.

Root cause (confirmed)

scanInitialStatuses() reads the last N lines of session JSONL files via execFile('tail', ['-n', '50', ...]) to infer session status when no status file exists (e.g. CodeV launched while sessions were already running, before hooks could fire).

Node.js execFile has a default maxBuffer of 1 MB. For sessions with large assistant responses, the last 50 lines of the JSONL can far exceed this — observed: 2.1 MB for a session with a long study task. When maxBuffer is exceeded, execFile returns an error, which the code handled by resolving with an empty string:

execFile('tail', ['-n', '50', filePath], { encoding: 'utf-8', timeout: 3000 }, (err, stdout) => {
  resolve(err ? '' : stdout);  // maxBuffer exceeded → err → empty string → scan skipped
});

This caused the scan to silently skip the session → no status file written → purple dot forever.

Why 50 lines can be so large

JSONL stores one JSON object per line. An assistant entry contains the entire response (thinking blocks, tool results, code output) in a single line — one line can be hundreds of KB. 50 lines spanning several assistant entries easily exceeds 1 MB.

Why this was invisible

The catch {} blocks in the status scan pipeline swallowed all errors silently. No logging existed for scan failures, maxBuffer errors, or empty scan results.

Fix (PR #117)

1. Reduced tail -n 50 to tail -n 15 — the last ~5 lines are always system metadata (stop_hook_summary, turn_duration, last-prompt, permission-mode, bridge_status). Assistant entries are within 15 lines from the end. This reduced output from 2.1 MB to 28 KB.
2. Added maxBuffer: 5 * 1024 * 1024 (5 MB) as a safety net.
3. Added console.error on tail failure so it's no longer silent.
4. Added debug logging throughout the session detection and status scan pipeline ([session-status] and [detect-active] prefixed logs).
5. Replaced all catch {} with catch (err) { console.error(...) } in detection, cleanup, and scan code.

Open question: dot disappearing entirely

During debugging (before adding logs), the dot was observed to disappear entirely (not just purple, but gone — meaning isActive = false). This was intermittent:

Time	Dot state
Initial report	Purple
After some time	Gone
Later	Purple again

After adding debug logs and running in dev mode, detectActiveSessions() returned the session in activeMap every time — the disappearance was not reproduced. Possible explanations:

• A transient error in detection that happened to not recur during the logging session
• React state reset from webpack hot reload in dev mode
• User interaction (typing in search field) triggering a re-render that temporarily cleared state

No action taken on this — logging is now in place to diagnose if it recurs.

Reproduction

The purple dot bug triggers when:

1. A Claude Code session has large assistant responses (long study tasks, extensive code generation)
2. The session's last 50 JSONL lines exceed 1 MB total
3. The session's status file doesn't exist (CodeV launched after the session, or hooks didn't fire)

Network interruption is NOT required — it was coincidental in the original report.

Environment

• CodeV v1.0.73
• Claude Code 2.1.96
• macOS

[grimmerk]

Additional observations (live debugging)

Current state (while the bug is active):

Check	Result
PID 38926 alive?	✅ Yes (ps -p 38926 → S+ claude)
~/.claude/sessions/38926.json exists?	✅ Yes (entrypoint: cli, sessionId: 290bec82)
~/.claude/codev-status/290bec82.json exists?	❌ No — missing
Session in history.jsonl?	✅ Yes (17 entries, project: /Users/grimmer/git/fred-ff)
Dot in CodeV?	❌ Gone — not even purple anymore

Timeline:

1. Purple dot was shown for a while (persisted across multiple CodeV focus/unfocus cycles and tab switching)
2. User typed some text in the session input (did not send) — after this, the dot disappeared entirely
3. PID is still alive, session file exists, history.jsonl has entries — CodeV should detect it as active but doesn't show any dot

Implication: The issue is NOT just "status file deleted → purple dot". The session may also be dropping out of detectActiveSessions() entirely (no dot at all), despite the PID file existing and the process being alive. This suggests readClaudeSessions(500) or the matching logic in detectActiveSessions() is failing for this session, possibly due to the 500-session limit or a match failure.

Key question: Is scanInitialStatuses actually running for this session? The catch {} at main.ts:2003 would silently swallow any error in the scan path, making this invisible.

🤖 On behalf of @grimmerk — generated with Claude Code

[grimmerk]

Update: dot state is intermittent

The dot is flickering between purple and absent across multiple CodeV focus cycles:

Time	Dot state	detectActiveSessions	codev-status/290bec82.json
Initial report	Purple	✅ detected	❌ missing
After some time	Gone	❌ not detected	❌ missing
Later check	Purple again	✅ detected	❌ still missing

Constants throughout: PID 38926 alive, sessions/38926.json exists, history.jsonl has 17 entries.

Key insight: detectActiveSessions() intermittently fails to include this session in activeMap, even though all inputs (PID file, process alive, history.jsonl match) are valid. The 5s active cache amplifies each transient failure into a 5-second window. And the status file is NEVER rebuilt — scanInitialStatuses is either not being triggered or silently failing due to catch {}.

This confirms the fix needs to address both:

1. Why detection is intermittent — likely a catch {} swallowing an error in the for-loop (line 936) or the outer try/catch (line 957)
2. Why status file is never rebuilt — scanInitialStatuses silent failure + cleanupStaleStatuses deleting the file on detection-miss cycles

🤖 On behalf of @grimmerk — generated with Claude Code

[grimmerk]

Root cause found and fixed

The bug: scanInitialStatuses() uses execFile('tail', ['-n', '50', ...]) to read the last 50 lines of the session JSONL. Node.js execFile has a default maxBuffer of 1 MB. For sessions with large assistant responses (study tasks, long code generation), the last 50 lines can exceed 1 MB — in this case, 2.1 MB for just 50 lines.

When maxBuffer is exceeded, execFile errors silently (err is set), and the scan resolves with '' → if (!tail.trim()) return skips the session → no status file is written → purple dot forever.

Why 50 lines can be so large: JSONL stores one JSON object per line with no wrapping. An assistant entry contains the entire response (thinking blocks, tool results, code output) in a single line — a single assistant line can be hundreds of KB.

The fix (in this PR branch):

1. Reduced tail -n 50 to tail -n 15 — the last ~5 lines are always system metadata, assistant entries are typically within 10-15 lines from the end. This reduced output from 2.1 MB to 28 KB.
2. Added maxBuffer: 5 * 1024 * 1024 (5 MB) as a safety net.
3. Added console.error on tail failure so it's no longer silent.

Result: The purple dot session (290bec82) now correctly shows green (idle).

Previous theories about cleanupStaleStatuses and detectActiveSessions intermittency were wrong — the logs showed detection was working correctly every time. The sole issue was the scan's silent maxBuffer failure.

🤖 On behalf of @grimmerk — generated with Claude Code

[grimmerk]

Note on earlier comments

The three comments above contain investigation notes from before the root cause was identified. Key corrections:

• cleanupStaleStatuses deleting the file — was a hypothesis, not confirmed. The actual root cause was execFile maxBuffer overflow in scanInitialStatuses.
• detectActiveSessions intermittently failing — was a hypothesis. Debug logs showed detection worked correctly every time it was observed. The "dot disappearing" symptom was not reproduced after logging was added; its cause remains unknown.
• "Previous theories were wrong" in the last comment was correct — the issue body has been rewritten to reflect the confirmed root cause only.

These comments are kept for historical context but should not be treated as accurate analysis.

🤖 On behalf of @grimmerk — generated with Claude Code