Skip to content

fix(daemon): auto-continue scans every agent slot window, not just slot 1#56

Closed
AliHamzaAzam wants to merge 1 commit into
feat/multi-device-remotefrom
fix/auto-continue-slot-windows
Closed

fix(daemon): auto-continue scans every agent slot window, not just slot 1#56
AliHamzaAzam wants to merge 1 commit into
feat/multi-device-remotefrom
fix/auto-continue-slot-windows

Conversation

@AliHamzaAzam

Copy link
Copy Markdown
Owner

Problem

Auto-continue never fired for agents in slot windows. The watcher enumerated lanes (slot windows counted for enumeration since an earlier fix) but then captured via tmux.capture(lane, ...), which resolves to the lane's slot-1 window. A rate-limit pause in lane-N-2+ was invisible: no detection, no RateLimited status, no log lines, no resume. Found live: an agent in lane-81-4 sat on "You've hit your session limit · resets 7am" for six hours past its reset.

Fix

  • Scan every managed window individually (managed_windows replaces the lane-deduped scan).
  • Key the private schedule and the public rate_limits map by window; send menu keys and the continue message to the specific paused window.
  • Overlay the pause onto the session bound to that window via tmux_window (previously: always the first non-external session), with a fallback so a momentarily-unpaired window still surfaces.
  • The per-lane C toggle still disarms all of a lane's slots.

Testing

  • New unit test managed_windows_scans_every_slot_window (failed before the fix); full workspace suite + clippy green.
  • Live verification in an isolated instance (own socket/config/tmux server): fake agent printing the session-limit message in lane-1-2 while a healthy agent runs in lane-1; the daemon detected, chose the window correctly, typed continue, and the slot-2 agent resumed with zero stray keys in slot 1.

Note

Stacked on #55 (touches the same rpc.rs region); retarget to main after it merges. Deploying this fixes the currently-stuck agent on next daemon restart, with one caveat: a stale limit message whose reset passed more than the parse grace ago schedules for the next day, so a long-stuck agent may still want one manual continue.

🤖 Generated with Claude Code

…ot 1

The watcher captured one pane per lane via the lane's default window
name, so a usage-limit pause in slot 2+ (lane-N-2, lane-N-3, ...) never
reached detect_usage_limit: no tracking, no RateLimited status, no
resume. Scan every managed window individually, send keys and the
continue message to the specific paused window, key the schedule and the
public rate_limits map by window, and overlay the pause onto the session
bound to that window (falling back to the first managed session when the
pairing is momentarily unknown). The C toggle stays lane-scoped.

Verified live in an isolated instance: a fake agent paused in lane-1-2
was detected and resumed while slot 1 received no stray keys.
Copilot AI review requested due to automatic review settings July 17, 2026 09:11

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

@AliHamzaAzam
AliHamzaAzam deleted the branch feat/multi-device-remote July 17, 2026 09:18
@AliHamzaAzam
AliHamzaAzam deleted the fix/auto-continue-slot-windows branch July 17, 2026 09:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants