oikos/plans/done/2026-07-15-whatsapp-session-audit.md

# 2026-07-15 — WhatsApp session audit: approvals, stuck indicator, stale executions

**Status:** Done — 2026-07-15. P1–P5 implemented; build + tests + vet pass.
Session audit of the WhatsApp bridge
investigation (`20757eb9`) following the plan-first + iteration deploy.
Four issues reported by the operator, each traced to a distinct root cause.

## Session under audit

| Session | Goal | Messages | Outcome |
|---|---|---|---|
| `20757eb9` | Diagnose and fix the Matrix WhatsApp bridge (stopped delivering messages) | 3 (1 user, 2 assistant) | success — image was 3 months old, `docker compose pull` fixed it |

The agent correctly diagnosed a 405 protocol-version rejection, pulled the
latest image, and the bridge reconnected. The structural fixes all worked
(plan-first gate refused the first `run` before `propose_plan`, plan was
proposed, writeback happened, `complete_task` closed the loop). But the UX
around the execution was wrong.

---

## Findings

### F1 — Two approvals instead of one (BLOCKER, misclassification + prose)

**What happened:** The agent proposed a 6-step plan and immediately started
executing steps 1-2 (read-only inspection: `docker compose logs`,
`docker compose ps`). Both `run` calls were classified as `config_mutation`
and queued for individual approval. The operator saw two approval cards
instead of one plan-level approval.

**Root cause A — `docker compose` subcommands missing from read-only
allowlist.** `internal/policy/command.go:69-78` has `docker\s+(ps|images|
inspect|logs|version|info|stats)` but NOT `docker compose` subcommands.
`docker compose logs` and `docker compose ps` are read-only inspection
verbs that the classifier escalates to `config_mutation`. This is the same
class of bug as the `find` omission from the Proton Drive audit (P4).

**Root cause B — agent didn't stop after proposing.** The `propose_plan`
return text says "If any step is config_mutation/destructive, STOP and wait
for operator approval." The agent ignored this — it started executing in the
same turn. This is prose enforcement, not structural. Combined with root
cause A, the read-only steps generated approval cards.

### F2 — Agent indicator stuck at "Approval: Check WhatsApp bridge..." (FRICTION)

**What happened:** After the session completed (status=`done`), the agent
indicator at the bottom of the chat stayed stuck showing "Approval: Check
WhatsApp bridge container status on elementsynapse" with a spinner.

**Root cause:** `web/src/lib/stores/activity.ts:131-150` creates an
`approval` entry with `status: 'running'` whenever a tool result contains
"requires approval." This entry is **never transitioned to `done`** — the
derived store rebuilds from messages on every poll, but the approval entry
is always set to `status: 'running'` (line 146). The `AgentIndicator`
(`Chat.svelte:153`) shows the first `running` entry from `$activityLog`,
so it latches onto the stale approval entry and never clears.

There's no mechanism to check whether the execution has actually completed
— the activity store derives purely from tool-call text, not execution
status from the API.

### F3 — Green "Completed in 1s on lxc:..." boxes in chat (COSMETIC)

**What happened:** Green success cards (`InlineApproval.svelte:154-163`)
rendered inline in the chat message stream for each completed execution.

**Root cause:** `Chat.svelte:144-146` renders `<InlineApproval>` inside
each message bubble when `msg.pendingApprovals.length > 0`. The
`InlineApproval` component shows the full approval lifecycle (pending →
running → completed/failed) inline in the chat. The operator considers
this noise — execution results belong in the activity sidebar, not in the
chat stream. The chat should show the agent's text + tool call summary, not
approval UX.

### F4 — 98 stale non-terminal executions (COSMETIC, ops debt)

**What happened:** 98 executions in non-terminal states
(39 `running`, 19 `pending_approval`, 3 `approved`, 37 more `running`
orphaned) from eval testing.

**Breakdown:**
- 39 `running` executions from `apt_upgrade:audit` actions — these were
  created by the MCP `run` handler, then the MCP call timed out (30s
  context deadline), leaving the execution in `running` state forever.
  Not linked to any session (orphaned).
- 19 `pending_approval` — config_mutation `run` calls that were queued for
  approval but never approved/denied (eval sessions that completed without
  resolving them).
- 3 `approved` — approved but never executed (the execution dispatch
  failed or timed out).

**Root cause:** No startup or periodic cleanup of stale executions. The
`run` handler creates an execution entity BEFORE attempting SSH — if the
SSH call times out or the MCP connection drops, the execution is
orphaned in `running` state. `completeTask` cancels pending approvals for
its own session, but nothing cleans up orphaned executions or old
sessions' leftovers.

---

## Improvement plan

### P1 — Add `docker compose` read-only subcommands to allowlist

**Fix:** `internal/policy/command.go` — add to `readOnlyLeadPattern`:
`docker\s+compose\s+(logs|ps|top|config|images|port|cp)\b`.
Do NOT add `docker compose exec` or `docker compose run` — these execute
arbitrary commands and must stay gated.

Add unit test case: `"docker compose logs --tail=100"` → `read_only`.

**Severity:** blocker (directly caused the two-approval issue).
**Files:** `internal/policy/command.go:69-78`, `command_test.go`.

### P2 — Fix stuck agent indicator

**Fix:** `web/src/lib/stores/activity.ts:131-150` — the approval entries
are always `status: 'running'` and never transition. Two options:

**Option A (recommended): Remove approval entries from activityLog
entirely.** They're already rendered as `InlineApproval` cards in the chat
(or, after P3, in the Operations page). Duplicating them in the activity
log causes the stuck indicator — the activity store derives from tool-call
text, not execution status, so it can't know when the execution completed.
Removing them means `AgentIndicator` won't latch onto stale approval
entries.

**Option B: Fetch execution status.** When building approval entries,
call `getExecution(execId)` to check the real status. This is more
correct but adds async API calls to a synchronous derived store — would
require restructuring the store to be async or pre-fetching statuses.

**Decision:** Option A — simpler, eliminates the bug class. If the
operator wants approval status in the activity sidebar, that's a separate
feature that should use the REST `/approvals` endpoint (already used by
`context.ts` and `Ops.svelte`), not text parsing of tool results.

**Severity:** friction.
**Files:** `web/src/lib/stores/activity.ts:131-150`.

### P3 — Move InlineApproval out of chat, into activity sidebar

**Fix:** Remove `<InlineApproval>` from `Chat.svelte:144-146`. The chat
stream shows only the agent's text + `ToolCallGroup` (the compact tool
counter). Approval UX (Approve/Deny buttons, completed/failed cards)
moves to the Operations page (already has it via `Ops.svelte`) and/or a
dedicated approval panel in the sidebar.

The `pendingApprovals` field on `ChatMessage` can stay (for counting
badges in the session rail), but the inline rendering is removed.

**Migration:** `InlineApproval.svelte` is not deleted — it's reused in
the Operations page or a new sidebar approval panel. The component's
props (`PendingApproval[]`) and API (`getExecution`, `decideApproval`)
stay the same.

**Severity:** cosmetic.
**Files:** `web/src/pages/Chat.svelte:144-146`.

### P4 — Stale execution cleanup

**Fix:** Add a startup cleanup + periodic sweep in nomos:

1. **Startup cleanup:** on `nomos serve` boot, mark all non-terminal
   executions older than 1 hour as `cancelled` with result
   `{"message": "cleaned up at startup — stale from prior session"}`.
   This handles the 98 stale executions from eval testing.

2. **Run handler fix:** in `internal/mcp/server.go` `classifyAndGate`,
   the execution entity is created (line 1284-1293) BEFORE the SSH call.
   If the SSH call fails or times out, the execution is already marked
   `running` but never transitions. The error paths (lines 1315-1321,
   1333-1340, etc.) already mark `failed` — but the MCP client timeout
   (30s, in `agent.go`'s `client.callTool`) kills the connection before
   the error path runs. Fix: move the execution entity creation to AFTER
   the SSH call succeeds, or add a `running` → `failed` timeout sweep.

3. **Periodic sweep:** add a 5-minute timer (like the continuation
   worker) that marks executions in `running` state for more than 10
   minutes as `failed` with result `{"message": "execution timed out"}`.
   This catches orphaned executions that the run handler didn't clean up.

**Severity:** cosmetic (ops debt, not a functional bug).
**Files:** `cmd/nomos/main.go` (startup), `internal/mcp/server.go`
(run handler), `cmd/nomos/continue.go` (periodic sweep).

### P5 — Enforce "stop after proposing a plan with config_mutation steps"

**Fix:** This is the structural enforcement gap behind the "agent didn't
stop after proposing" behavior. The `propose_plan` return text says "STOP
and wait" but nothing enforces it. Two options:

**Option A (structural):** In the `run` handler (`classifyAndGate`), after
the plan-first gate, check if the plan has any `config_mutation` steps
AND no assent window is active. If so, refuse the `run` with "This plan
has config_mutation steps — wait for operator approval before executing."
This would force the agent to stop after proposing, but it would also
block the legitimate case where the operator already said "go ahead" (the
assent window would be active, so the check would pass).

**Option B (prose):** Strengthen the `propose_plan` return text and
SOUL.md to be more directive. This is what we've been doing — it works
for strong models but not for weaker ones.

**Decision:** Option A — structural enforcement. The check is simple
(assent window active?) and catches the exact case where the agent
proposes a plan with config_mutation steps and starts executing without
approval. Read-only steps still auto-execute (they don't need the
assent window).

**Severity:** friction (prevents the two-approval UX, but doesn't block
functionality).
**Files:** `internal/mcp/server.go` `classifyAndGate`, `nomos/SOUL.md`.

---

## Sequencing

- **P1** (docker compose allowlist) is independent — ship immediately.
- **P2** (stuck indicator) + **P3** (inline approval removal) ship
  together — both touch the chat rendering surface.
- **P4** (stale cleanup) is independent — ship anytime.
- **P5** (config_mutation enforcement) depends on P1 (the allowlist fix
  reduces false config_mutation classifications) — ship after P1.

## Verification

- `go test ./internal/policy/...` — new `docker compose logs` read-only
  test case.
- Manual: replay the WhatsApp bridge prompt, confirm a single plan-level
  approval (not two), no stuck indicator, no green boxes in chat.
- `docker exec oikos-postgres-1 psql -U oikos oikos -c "SELECT COUNT(*)
  FROM executions WHERE status NOT IN ('completed','failed','cancelled')"`
  → 0 after the startup cleanup runs.