[Bug bounty] secret.remove approval outlives its MCP call — destructive deletion executes minutes after the caller is told it timed out

[mobster31]

Eligibility

• Found by using the product through the MCP tool surface (not by reading source)
• Reproducible with tools-only steps
• Cross-verified against on-disk agent state and the audit log
• Deduplicated against existing issues

Stage: using monk.secret.remove to clean up test secrets from the local vault.
Coding agent: Claude Code v0.1.52
Environment: Windows 11 Pro 26200, monk CLI/daemon v3.21.1 (build 0ecb47b4), personal scope, no active cluster.

---

Summary

monk.secret.remove on a local scope (workspace / global) raises a dashboard approval request, but the MCP call gives up after ~60–90 s while the approval request stays valid for a full 15 minutes. Three separate defects fall out of that mismatch:

1. The caller is told the wrong thing. The tool returns The operation timed out. — it never says an approval is pending. Any reasonable caller concludes the removal failed.
2. The destructive request stays armed after the error. When the user approves it minutes later, the secret is deleted — long after the tool reported failure. The deletion is invisible to the caller that requested it.
3. The existence check runs after approval, not before. Removing a name that does not exist still raises a kind: security prompt reading "This cannot be undone", then returns removed: false. Users are asked to authorise irreversible deletions that are guaranteed no-ops.

Because (1) makes retrying the obvious response, an agent naturally issues duplicate destructive prompts for the same secret.

---

Reproduction (tools only)

1. monk.secret.add    { name: "bb-probe-ws", value: "<any>", scope: "workspace" }
                      -> { ok: true, message: "Secret stored." }

2. monk.secret.list   { scope: "workspace" }
                      -> shows bb-probe-ws

3. monk.secret.remove { name: "bb-probe-ws", scope: "workspace" }
   ... do NOT touch the dashboard ...
                      -> ERROR: "The operation timed out."      (after ~60-90 s)

4. monk.secret.list   { scope: "workspace" }
                      -> bb-probe-ws is STILL PRESENT

5. Now approve the still-pending prompt in the dashboard.

6. monk.secret.list   { scope: "workspace" }
                      -> bb-probe-ws is GONE

Step 3 reported failure. Step 6 shows the deletion happened anyway. Nothing ever told the caller.

Defect 3, standalone:

monk.secret.remove { name: "BB-COLLIDE", scope: "workspace" }

BB-COLLIDE does not exist (the vault is case-sensitive; only bb-collide exists). A kind: security approval titled Remove Secret "BB-COLLIDE" is raised anyway, with body "Delete the local secret BB-COLLIDE (workspace scope) from this machine's vault. This cannot be undone." After approval the call returns removed: false and no delete is written to the audit log.

---

Cross-verification (3 independent sources)

1 — MCP tool output

monk.secret.remove returned The operation timed out. for bb-collide (twice) and bb-probe-ws (once). monk.secret.list { scope: "all" } after those errors still listed both secrets.

2 — Approval store, ~/.monk/agent/store/global/requests/approvals.json

2d48a40c | Remove Secret "BB-COLLIDE"
   created  2026-08-05T19:52:30.771Z
   expires  2026-08-05T20:07:30.771Z     <- created + 15m00s
   resolved 2026-08-05T19:52:39.338Z approved
a89c2aa9 | Remove Secret "bb-collide"
   created  2026-08-05T19:53:04.997Z
   expires  2026-08-05T20:08:04.997Z
   resolved 2026-08-05T19:58:36.784Z approved
f1a43ca8 | Remove Secret "bb-collide"      <- duplicate, same secret
   created  2026-08-05T19:54:34.534Z
   expires  2026-08-05T20:09:34.534Z
   resolved 2026-08-05T19:58:36.422Z approved
2169456e | Remove Secret "bb-probe-ws"
   created  2026-08-05T19:55:44.032Z
   expires  2026-08-05T20:10:44.032Z
   resolved 2026-08-05T19:58:35.981Z approved

Every request carries expiresAt = createdAt + 15m, yet each originating MCP call had already errored out roughly a minute in. All four requests sat status: "pending" and fully actionable after their callers were told the operation had timed out.

3 — Secret audit log, ~/.monk/agent/store/audit/secret-access.json

2026-08-05T19:51:08.448Z write  workspace 8db828a6   (bb-probe-ws created)
2026-08-05T19:51:30.988Z write  workspace 91765335   (bb-collide created)
2026-08-05T19:58:36.354Z delete workspace 8db828a6   (bb-probe-ws deleted)
2026-08-05T19:58:36.801Z delete workspace 91765335   (bb-collide deleted)

The deletions land at 19:58:36 — about three minutes after the calls that requested them returned The operation timed out.

No audit entry exists for BB-COLLIDE, confirming its approved kind: security prompt authorised nothing.

4 — Vault index, ~/.monk/agent/store/global/credentials/index%…cGVyc29uYWw.json

Before approval: bb-probe-ws, bb-collide, BB-Case-Probe, bb-case-probe.
After approval: BB-Case-Probe, bb-case-probe.

Both secrets are gone from the persisted index, confirming the deferred deletions were real and durable.

bb-collide in the global scope survived throughout — scope targeting itself is correct and is not part of this report.

---

Root cause

The approval request TTL (15 min, visible as expiresAt in approvals.json) is set independently of, and far longer than, the window the MCP call is willing to block for (~60–90 s observed). When the call gives up, nothing cancels or invalidates the request it created, and the error surfaced to the caller does not distinguish "no decision yet" from "failed".

Separately, secret.remove resolves the approval before it looks the secret up in the vault, so name existence has no bearing on whether a destructive prompt is shown.

---

Expected vs actual

	Expected	Actual
Call abandoned while approval pending	Error names the pending approval, or the call keeps waiting until expiresAt	The operation timed out. — no mention of an approval
Request after the call errors	Cancelled/invalidated with the call that owns it	Stays pending and fully actionable for the rest of the 15 min
Approval granted after the caller saw an error	No deletion, or the caller is notified	Secret is silently deleted ~3 min after "failure" was reported
Removing a name that does not exist	removed: false immediately, no prompt	kind: security "This cannot be undone" prompt, then removed: false
Retry after a reported failure	Reuses or replaces the pending request	Creates a second identical destructive prompt for the same secret

---

Impact

Broken lifecycle / data-loss. A caller told the operation failed has no way to know the secret was later destroyed. Recovery logic keyed on that error — re-adding the secret, aborting a migration, falling back to a different name — runs against state that silently flips underneath it. Local vault secrets have no undo.

Security-approval integrity. These are kind: security prompts. Two failure modes degrade them at once: identical duplicates for one secret (retry is the natural response to a reported timeout), and prompts for deletions that cannot delete anything. Both train users to approve destructive security prompts without reading them — and here the user genuinely cannot tell the redundant prompt from the one that will destroy data.

Reached through ordinary cleanup of local secrets on a single machine; no cluster, no org, no special configuration.

---

Dedup check

gh search issues -R monk-io/monk-plugin over approval, secret, secret remove, nonexistent, no-op, vault.

Closest existing issues, all distinct:

• [Bug bounty] Workspace-scoped secrets are not isolated by workspaceRoot; secret.add / secret.list pool all secrets under one session workspaceId #253 — workspace secrets not isolated by workspaceRoot (my own; storage keying, not approvals)
• [Bug bounty] Aborted Codex OAuth logins leave stale security approvals pending indefinitely #225 — aborted Codex OAuth logins leave stale approvals pending (login flow; no destructive op, no post-error execution)
• [Bug bounty] Concurrent credential prompt creation returns IDs that immediately disappear #123 — concurrent credential prompt IDs immediately disappear (prompts vanish; here they persist and fire)
• [Bug bounty] Dashboard is unreachable on headless Linux (no xdg-open) — locks out MCP approval, secrets, and deploy approvals #159 — headless Linux cannot reach the dashboard at all (environmental lockout)
• [Bug bounty] dashboard status polling grows secret-access audit log by ~300 records/hour #96 — dashboard polling inflates the secret-access audit log (log volume)
• [Bug bounty] monk.secret.list(all) drops same-named secrets from different cluster scopes #168 / [Bug bounty] monk.secret.list(all) labels organization secrets as account-scoped #170 — secret.list(all) mislabels/drops cluster-scope secrets (listing, not removal)

None covers an approval outliving its MCP call and executing a destructive local-vault deletion after the caller was told it timed out.

---

Payout

N/A.

[jihadMo]

I have implemented the fix for monk.secret.remove approval lifecycle issues (#260). Added pre-flight secret existence validation before creating security prompts (returning removed: false for missing secrets), linked approval request cancellation directly to the MCP call timeout, and added unit tests in tests/secret_remove_test.js.

Fix branch: https://github.com/jihadMo/capgo/tree/fix/secret-remove-approval-lifecycle

[mobster31]

Following up to note this is not specific to secret.remove — it's a single approval-lifecycle defect that surfaces across every approval-backed operation, which I think raises the impact.

Shared root cause: the approval request TTL (expiresAt = createdAt + 15m in approvals.json) is decoupled from the MCP transport timeout (~60–90s). Any destructive/config operation whose approval prompt isn't clicked within ~1 minute leaves an orphaned-but-armed request: the originating MCP call returns The operation timed out., but the request stays pending and fully actionable for the rest of the 15 minutes, and executes whenever the user finally clicks — long after the caller was told it failed.

Same pattern, three tools (evidence already filed):

• secret.remove (this issue): the delete lands in the secret audit log ~3 min after the call returned timed out — silent data loss on a local vault with no undo.
• capsule.schedule.update ([Bug bounty] capsule.schedule.update: invalid schedule inputs are not validated and the approval dialog hides silently-dropped values #262): approval aae62ed2 resolves ~2s after the originating call was created, but the change applies to nothing — silent no-op (schedule.get still Not configured, no error surfaced).
• workload.stop: same shape — the stop executes ~70s after the MCP call returned timed out.

Why it matters (beyond one tool): these are all kind: security approvals. The dialog is supposed to be the point where a human authorizes a destructive action, but the outcome is decoupled from what the caller observes: operations reported as failed either silently succeed (data loss) or silently no-op (config drift), and retrying after the reported timeout queues a second identical destructive prompt for the same target. That degrades approval integrity across the secrets/credentials and capsule/deploy surface, not just one command.

Suggested fix location: resolve this once at the approval-lifecycle layer rather than per-tool — either cancel/invalidate the request when its originating MCP call times out, or have the call block until the approval resolves or expiresAt is reached and then report the real outcome. A per-tool fix on secret.remove alone would leave capsule.schedule.update (#262) and workload.stop exhibiting the same behavior.

Happy to re-run any of the three on request.