Reactions leak into background task lane via shared IPC input directory

[Peyton-Spencer]

Bug

When a reaction arrives while a background task is running, the reaction message gets piped into the background task's active agent query instead of only reaching the message lane.

Observed behavior

Logs from a session where the task lane was running an accessibility audit and a 💚 reaction came in:

[agent-runner] [msg #98] tool=Bash grep -n "sr-only" ...    ← task lane working
[agent-runner] [msg #99] type=user
Reaction on bot message in Discord                          ← reaction arrives
[agent-runner] Piping IPC message into active query (164 chars)  ← LEAKED into task
[agent-runner] [msg #10] type=system/init                   ← message lane also spins up
[agent-runner] Session initialized: 47c712a1-...

The reaction was handled by both:

1. A new message-lane session (correct) — responded with <internal> no-response
2. The running task-lane agent (incorrect) — piped in via IPC, agent happened to ignore it

Expected behavior

Reactions (and all message-lane IPC) should only reach the message-lane container, never the task-lane container.

Root cause

queue.sendMessage() writes to the input/ IPC directory. Task containers are supposed to be isolated via an overlaid mount (input-task/ → /workspace/ipc/input/), but the reaction message still reached the task container's active query.

Relevant code:

• Host write: group-queue.ts:231 — sendMessage() writes to data/ipc/{folder}/input/
• Mount setup: local-backend.ts:147-162 — task containers mount input-task/ over input/
• Container read: agent-runner/src/index.ts:512-516 — drainIpcInput() polls /workspace/ipc/input/

The mount overlay (input-task/ → /workspace/ipc/input/) may not fully isolate the directories, possibly due to Apple Container mount ordering or timing.

Impact

• Low severity now: Reactions generate short messages the agent tends to ignore
• High severity potential: If a user sends a real message while a task is running, the message content could be injected into the task agent's context, causing it to act on unrelated instructions mid-task

Possible fixes

1. Verify mount isolation: Debug whether the Apple Container overlaid mount actually shadows input/ for task containers — may need container exec to confirm
2. Separate directory trees entirely: Instead of mount overlays, use completely separate IPC root dirs per lane (e.g., ipc-message/ and ipc-task/) and pass the path via env var to the agent-runner
3. Lane-aware IPC polling: Add a NANOCLAW_IPC_LANE env var so the agent-runner knows which subdirectory to poll, rather than hardcoding /workspace/ipc/input

[Peyton-Spencer]

After reviewing the code, I can confirm the root cause analysis. The mount overlay strategy at local-backend.ts:156-162 attempts to shadow input/ with input-task/ for background tasks, but Apple Container's mount semantics may not fully isolate these overlays.

Key insight: The issue likely stems from mount timing. If the agent-runner starts polling /workspace/ipc/input/ before the overlay mount is fully applied, or if Apple Container allows both mounts to be visible simultaneously, messages from input/ can leak into the task container.

Recommended fix (Option 2): Separate IPC directory trees entirely is the most robust solution:

// In local-backend.ts
const ipcRoot = isScheduledTask 
  ? path.join(groupIpcDir, 'ipc-task')
  : path.join(groupIpcDir, 'ipc-message');

mounts.push({
  hostPath: ipcRoot,
  containerPath: '/workspace/ipc',
  readonly: false,
});

Then in agent-runner, poll the correct directory:

const ipcInputDir = process.env.NANOCLAW_IPC_LANE === 'task' 
  ? '/workspace/ipc-task/input'
  : '/workspace/ipc-message/input';

This eliminates reliance on mount overlay semantics and guarantees lane isolation. The current mount strategy is clever but fragile given Apple Container's limitations.

Alternative quick fix: Add lane filtering in agent-runner's drainIpcInput() — check a lane field in IPC messages and drop messages not matching the container's lane. Less elegant but faster to implement.

[Peyton-Spencer]

Debugging Strategy

To diagnose the mount isolation issue, I recommend:

1. Verify Mount Overlay

# From host, exec into task container
container exec <task-container-id> ls -la /workspace/ipc/input/
container exec <task-container-id> cat /proc/self/mountinfo | grep input

Compare against message container to confirm input-task/ is actually shadowing input/.

2. Timing Issue Theory

The reaction might arrive during a mount race condition:

• Container starts with overlay mount
• Host writes to input/
• Mount hasn't fully propagated yet
• drainIpcInput() catches the file before it's shadowed

Test: Add a 100ms delay after container spawn before allowing IPC writes.

3. Atomic Fix (Recommended)

Use separate directory trees per lane:

// local-backend.ts
const ipcRoot = lane === 'task' 
  ? path.join(dataDir, 'ipc-task')
  : path.join(dataDir, 'ipc-message');

containerInput.env.NANOCLAW_IPC_ROOT = ipcRoot;

Then in agent-runner:

const ipcDir = process.env.NANOCLAW_IPC_ROOT || '/workspace/ipc';
const inputDir = path.join(ipcDir, 'input');

This eliminates mount complexity entirely.

---

Security Note: Per Issue #79, this leak could also expose API keys if they were passed via IPC messages (they're not currently, but worth considering for the fix design).