[Security] Agent auto approve consent after timeout #139

Activity

1. Suzhen Zheng (benniao85)

   assigned

   yikkuro (yikkuro)

   on Aug 11, 2026
2. yikkuro commented on Aug 25, 2026

   

   yikkuro (yikkuro)

   on Aug 25, 2026

   Contributor

   More actions

   Verified against current main, including the Windows Node + MXC work merged through PR #216: unanswered permission requests fail closed and do not become approvals.

   • The existing AppContainer file/shell/app permission path uses a 60-second timeout (SANDBOX_PERMISSION_TIMEOUT_MS = 60_000). Its timeout branches return deny, so the blocked operation remains denied.
   • Ordinary Gateway approvals for Windows Node/MXC expire after 1,800,000 ms (30 minutes). Expiry resolves to no decision; the enforced MXC policy has askFallback=deny, so the command is reported back as Exec denied (..., approval-timeout) and node.invoke is not called.
   • A timeout does not write a durable approval. Durable MXC records are created only after an explicit allow-always response with a fully bound command identity; deny and allow-once do not persist.
   • Internal MXC readiness probes do not use the user permission queue. They use narrowly scoped, one-use proofs with a 15-second expiry; an absent, expired, replayed, or mismatched proof fails readiness and keeps ingress closed.

   The relevant regression coverage includes constants.test.ts, sandbox-logic.test.ts, windows-node-mxc-durable-approvals.test.ts, openclaw-approval-replay-compat.test.ts, windows-node-mxc-readiness-proof.test.ts, bundled-windows-node-host.test.ts, PermissionDialog.test.ts, and the Windows-host approval/readiness tests. PR #216 also removes the pinned Gateway's expired implicit approval replay path by requiring a fresh valid approval.

   Closing this as completed because the reported timeout-to-approval security behavior is not present in current main.
3. yikkuro (yikkuro)

   closed this as completedon Aug 25, 2026