Temporary time-bound exec security escalation via /trust and /untrust commands.
Problem to solve
Existing exec approval workflows (deny/allowlist/full) are binary and permanent per session. Users who want exec.security=full for a focused coding session must either:
- Set it permanently with
/exec security=full and remember to revert (most forget)
- Leave approvals enabled and endure per-command confirmation friction that disrupts flow
This leads to a common anti-pattern: users disable exec approvals entirely, defeating the security model. There is no existing middle ground between "always approve" and "always allow."
Proposed solution
Add /trust [minutes] and /untrust slash commands:
/trust [minutes] — temporarily sets exec.security=full for the current session (1-480 minutes, default 15)
/untrust — revokes trust immediately
- Anti-stacking: refuses to extend while active (must /untrust first then /trust again)
- In-memory only: trust is lost on process restart (fail-closed by design)
- Single decision point in resolveExecOverrides for all surfaces (CLI, TUI, Discord, Telegram, Slack, WhatsApp, web)
- Uses existing rejectUnauthorizedCommand gate for authorization
This follows the same temporary escalation pattern used by sudo timeouts and OAuth token expiry — granting elevated access for a bounded window with automatic revocation.
Alternatives considered
- Per-command approval with "approve all for N minutes" — requires deeper changes to the approval flow and UI across all surfaces
- Config-level timeout on /exec security=full — would change existing /exec semantics and require migration
- Allowlist-based auto-approval — doesn't address the "I want full access for this task" use case. There is some work to do someday to make Safebins environmental rather than filter-based someday.
Impact
- Affected: All users who interact with exec approvals across any surface
- Severity: Medium — current friction leads users to disable approvals entirely
- Frequency: Every coding session where exec is needed
- Consequence: Improved usable security surface — users can grant temporary full access instead of permanently disabling protections
Evidence/examples
- sudo: grants root for a configurable timeout window (default 5-15 minutes)
- AWS STS: temporary credentials with explicit TTL
- GitHub fine-grained PATs: time-bounded access tokens
- Mobile biometric unlock: trust device for N minutes after authentication
Additional information
Temporary time-bound exec security escalation via /trust and /untrust commands.
Problem to solve
Existing exec approval workflows (deny/allowlist/full) are binary and permanent per session. Users who want exec.security=full for a focused coding session must either:
/exec security=fulland remember to revert (most forget)This leads to a common anti-pattern: users disable exec approvals entirely, defeating the security model. There is no existing middle ground between "always approve" and "always allow."
Proposed solution
Add
/trust [minutes]and/untrustslash commands:/trust [minutes]— temporarily sets exec.security=full for the current session (1-480 minutes, default 15)/untrust— revokes trust immediatelyThis follows the same temporary escalation pattern used by sudo timeouts and OAuth token expiry — granting elevated access for a bounded window with automatic revocation.
Alternatives considered
Impact
Evidence/examples
Additional information