Sessions occasionally wiped by a burst of /clear with zero user input while a lane is left unattended

[danielmjrr]

Environment

• Lanes 0.45.2 (brew cask), macOS 26.x (Darwin 25.5.0, arm64)
• Agent: Claude Code (com.anthropic.claude-code), sessions run inside Lanes lanes
• Recurs roughly once a week; always while the affected lane is open but unattended

Summary

While a lane running an active Claude Code session is left open but unattended, Lanes injects a rapid burst of ~10–12 /clear commands into that lane's session with no user input — spaced ~1–3 s apart over ~20 s. In Claude Code each /clear wipes the conversation and starts a fresh session, so the burst destroys the in-progress session's context and spawns a chain of throwaway sessions.

The input demonstrably originates from Lanes, not from Claude: during the burst window there are zero agent/tool actions in the session (so nothing inside Claude issued them), Lanes (com.lanes.app) was the key/focused window receiving the events, and no Claude Code hook, background daemon, /loop, cron, or launchd job accounts for it. (The @lap-platform/lapsh SessionStart hook fires once per resulting cleared session, but that is downstream — a fingerprint of the clears, not their cause.)

Impact

Silent, in-place loss of an active session's context. Because it triggers while the lane is unattended, the user returns to find the session wiped with a stack of /clears they never typed and no indication of what happened. Recurs ~weekly.

Workaround

The lost session is recoverable. /clear doesn't delete the Claude Code transcript — the pre-clear session survives on disk and can be resumed by its ID: claude --resume <session-id> (find it under ~/.claude/projects/<project>/*.jsonl — the largest session whose last activity precedes the clear burst; the affected lane's running process names it via --session-id). This restores the full conversation, but only recovers work manually after the fact — it does not prevent the wipe, and the Lanes UI gives no indication the session was cleared.

Steps to reproduce

1. Open Lanes with an active Claude Code session running in a lane (agent working or idle).
2. Switch to and work in a session in a different project, leaving the first session open and running — don't end it, let Claude keep working.
3. Leave it unattended for ~10 minutes.
4. Return to the first lane → the session has been cleared; you'll often see ~10 /clear commands you never entered, and the conversation/context is gone.

Evidence (one captured occurrence, 2026-07-27 15:03 local)

• 12 /clear injected in 21 s (15:03:39–15:04:00), spaced 1.2–2.9 s apart — an app-level loop cadence, not a keystroke storm or human input.
• Delivered to Lanes (com.lanes.app, key/focused window) per the macOS unified log.
• Zero Claude tool calls in the window → the commands are external to the Claude session.
• Each /clear ended the current Claude Code session and created a new one → a chain of 6 short session files handing off within ~0.15 s of each other (proof it's one continuous lane being cleared repeatedly).
• Not attributable to Claude Code hooks, the Claude daemon session pool, /loop, cron, or launchd — all checked and excluded.