Bug Description

Slash commands like /stop, /model, and /compact experience a delay before taking effect. This is because they are processed through the same session lane queue as regular agent runs, causing them to wait behind any currently running agent operations.

Current Behavior

When a user sends /stop or /model while an agent run is active, the command is queued behind the current run and only executes after it completes. This makes the commands feel unresponsive and defeats their purpose as immediate control mechanisms.

Expected Behavior

Control commands like /stop, /model, /compact should bypass the session lane queue and execute immediately, even when an agent run is in progress.

Steps to Reproduce

1. Start a long-running agent operation (e.g., a complex query)
2. While the agent is processing, send /stop or /model some-other-model
3. Observe that the command doesn't take effect until the current run completes

Code Location

• Command handler: src/auto-reply/reply/commands-core.ts (line ~75)
• /stop handler: src/auto-reply/reply/commands-session.ts:287
• /compact handler: src/auto-reply/reply/commands-compact.ts:43
• Session lane queue: src/process/command-queue.ts (uses enqueueCommandInLane)
• Lane usage: src/agents/pi-embedded-runner/compact.ts:506

Technical Details

Commands are processed through handleCommands() which returns immediately, but the actual compaction/stop logic that uses compactEmbeddedPiSession() or aborts runs goes through enqueueCommandInLane() which serializes execution per session.

Proposed Solution

Option 1: Create a priority lane for control commands that bypasses the normal session lane
Option 2: Use a different queuing mechanism for commands that need immediate execution
Option 3: Check for active runs and abort them synchronously before queueing compaction

Related Code

// src/agents/pi-embedded-runner/compact.ts:506
return enqueueCommandInLane(sessionLane, () =>
  enqueueGlobal(async () => compactEmbeddedPiSessionDirect(params))
);