bug: mc_capture in serve mode only returns latest event despite reporting high totalEvents count

[nigel-dev]

Description

mc_capture in serve mode reports a high totalEvents count but only ever returns a single event (the latest "streaming" event). The actual tool calls, file edits, errors, and agent reasoning from the session are not retained or returned.

This makes serve mode jobs effectively unobservable after they complete — you can't see what the agent did, what tools it called, or why it stopped.

Steps to Reproduce

1. Launch a serve mode job:

   mc_launch({ name: "test-job", mode: "ulw", prompt: "..." })
   

2. Wait for the job to complete
3. Capture all events:

   mc_capture({ name: "test-job", filter: "all", lines: 200 })
   

4. Response shows totalEvents: 529 but events array contains only 1 entry:

   {
     "summary": {
       "totalEvents": 529,
       "filesEdited": 0,
       "currentTool": "streaming"
     },
     "events": [
       {
         "type": "tool",
         "timestamp": "2026-02-21T10:57:08.376Z",
         "payload": { "tool": "streaming" }
       }
     ]
   }

Expected Behavior

mc_capture should return the requested number of events (up to lines) with actual tool call details:

• Tool names (Read, Write, Edit, Bash, etc.)
• File paths for file.edited events
• Error messages for error events
• Timestamps for all events

The totalEvents count should match the number of events actually available for retrieval.

Actual Behavior

• totalEvents counter increments with SSE stream events from the serve mode connection
• Only the latest event is stored/returned regardless of the lines parameter
• All filter options (all, tool, file.edited, error) return the same single event or empty
• After job completion, there is no way to audit what the agent actually did

Impact

• Cannot debug why serve mode jobs succeed or fail
• Cannot verify agent work without manually checking the filesystem
• mc_status agent reports are the only visibility, and those are voluntary (agent must call mc_report)

Environment

• OS: macOS (Apple Silicon)
• tmux version: 3.5a
• opencode version: 1.2.10
• bun version: 1.2.5
• opencode-mission-control: latest (as of 2026-02-21)

Additional Context

Tested across 4 concurrent serve mode jobs. All showed the same behavior — high event counts (353–678) but only 1 event returned. The file.edited filter returned 0 events even though the filesEdited: 0 in summary suggests it's tracking that dimension (just nothing was edited in this case).