Make approvals and audit durable across non-CLI channels

[vaddisrinivas]

Problem

OpenHuman has approval and audit primitives, but approval is still mostly CLI/session-oriented and not consistently wired through channel, webhook, or generated-tool execution paths. Locked-down runtimes need a durable, inspectable approval/audit trail for side effects regardless of entrypoint.

Generic use case

A desktop user, channel user, or managed profile can review pending approvals, audit what the agent did, and replay/reject decisions across UI, channel, or webhook-triggered work.

Managed-runtime use case

A compiled runtime contract can require approval for medium/high-risk capabilities, write before/after audit entries, enforce TTL/idempotency, and fail closed when audit storage is unavailable.

Proposed shape

• Promote approval decisions and audit entries from in-memory/session-only structures to durable workspace storage.
• Add channel-safe approval request lifecycle: pending, approved, denied, expired.
• Add policy/audit hooks around generated/external capability tools.
• Ensure non-CLI paths do not silently auto-approve risky calls.

Acceptance criteria

• Tests cover approval request creation and expiry.
• Tests cover audit write before and after an action.
• Channel/webhook-triggered tool calls can be denied by policy instead of auto-approved.
• Audit output redacts tokens, credentials, and PII-heavy payloads.

Alignment

This is core safety infrastructure. It makes Composio actions, MCP actions, and built-in tools more trustworthy rather than replacing any integration provider.

[Alexxigang]

I investigated this and confirmed there is still an unowned slice here even with #2335 in flight: expires_at is persisted for pending approvals, but stale requests can still remain actionable after restart because the pending lifecycle does not currently enforce expiry in the store.\n\nI'm taking the expiry-lifecycle part of this issue: making stale pending approvals stop showing up as actionable pending rows after they expire, rejecting late decisions for expired requests, and adding regression coverage around the durable restart/orphaned-request path. I'll keep this scoped so it does not overlap with #2335's recent-decision audit read path.

[Alexxigang]

Update: I opened #2357 for the expired-request lifecycle slice of this issue. It makes the store eagerly transition stale pending approvals out of the actionable pending list, rejects late decisions for expired requests, and adds regression coverage for the restart/orphaned-request path.