Discord /trust advertises 480m max but enforces 60m

The option description says "max: 480" but the callGatewayRpc call doesn't pass force: true. When users try /trust minutes:120 or any value over 60, grantTrustWindow rejects it with: Duration exceeds default cap (60m). Use force to allow up to 480m. — contradicting the advertised max.

To fix, either:

1. Update the description to match the actual enforced max (60m), or
2. Add a force option to the Discord command and pass it through:

And in run():

const force = interaction.options.getBoolean("force") ?? false;
const result = (await callGatewayRpc(this.ctx.cfg, "exec.approvals.trust", {
  agentId,
  minutes,
  force,
  grantedBy: `discord:${interaction.user?.id ?? "unknown"}`,
})) ...

This is a comment left during a code review.
Path: src/discord/monitor/trust-command.ts
Line: 111-151

Comment:
**Discord `/trust` advertises 480m max but enforces 60m**

The option description says "max: 480" but the `callGatewayRpc` call doesn't pass `force: true`. When users try `/trust minutes:120` or any value over 60, `grantTrustWindow` rejects it with: `Duration exceeds default cap (60m). Use force to allow up to 480m.` — contradicting the advertised max.

To fix, either:
1. Update the description to match the actual enforced max (60m), or
2. Add a `force` option to the Discord command and pass it through:

```suggestion
  options: CommandOptions = [
    {
      name: "minutes",
      description: "Duration in minutes (default: 60, max: 480 with force)",
      type: ApplicationCommandOptionType.Number,
      required: false,
    },
    {
      name: "force",
      description: "Allow exceeding default 60m cap (up to 480m)",
      type: ApplicationCommandOptionType.Boolean,
      required: false,
    },
    {
      name: "agent",
      description: "Agent id (default: main)",
      type: ApplicationCommandOptionType.String,
      required: false,
    },
  ];
```

And in `run()`:
```ts
const force = interaction.options.getBoolean("force") ?? false;
const result = (await callGatewayRpc(this.ctx.cfg, "exec.approvals.trust", {
  agentId,
  minutes,
  force,
  grantedBy: `discord:${interaction.user?.id ?? "unknown"}`,
})) ...
```

How can I resolve this? If you propose a fix, please make it concise.

Good catch. Adding a force boolean option to the Discord command and threading it through the gateway RPC call. Description will be updated to (default: 60, max: 480 with force).

Status: Will fix in next commit.

exec.approvals.trust.status not advertised in features list

The method is fully implemented in execApprovalsHandlers and called by the TUI, but it's missing from BASE_METHODS. While the gateway router still handles requests to it, clients cannot discover it via the hello-ok features payload.

This is a comment left during a code review.
Path: src/gateway/server-methods-list.ts
Line: 29-30

Comment:
**`exec.approvals.trust.status` not advertised in features list**

The method is fully implemented in `execApprovalsHandlers` and called by the TUI, but it's missing from `BASE_METHODS`. While the gateway router still handles requests to it, clients cannot discover it via the `hello-ok` features payload.

```suggestion
  "exec.approvals.trust",
  "exec.approvals.untrust",
  "exec.approvals.trust.status",
```

How can I resolve this? If you propose a fix, please make it concise.

Correct — exec.approvals.trust.status should be listed for feature discovery. Will add it in the next commit.

Status: Will fix in next commit.

Inconsistent error response between trust and untrust handlers

When grantTrustWindow fails, this handler uses respond(false, ..., errorShape(...)), which causes the gateway client to reject the promise with a thrown Error. The CLI's if (!result?.ok) check (line 824 in exec-approvals-cli.ts) becomes dead code — errors throw instead of resolving to { ok: false }.

By contrast, exec.approvals.untrust (line 267) uses respond(true, { ok: false, ... }), which resolves cleanly and is handled by if (!result?.ok). This asymmetry also means the CLI test mocks (which use mockResolvedValueOnce({ ok: false, ... })) don't match the actual gateway behavior for the trust handler.

Make both consistent by using the application-level error pattern:

This is a comment left during a code review.
Path: src/gateway/server-methods/exec-approvals.ts
Line: 249-253

Comment:
**Inconsistent error response between `trust` and `untrust` handlers**

When `grantTrustWindow` fails, this handler uses `respond(false, ..., errorShape(...))`, which causes the gateway client to reject the promise with a thrown `Error`. The CLI's `if (!result?.ok)` check (line 824 in `exec-approvals-cli.ts`) becomes dead code — errors throw instead of resolving to `{ ok: false }`.

By contrast, `exec.approvals.untrust` (line 267) uses `respond(true, { ok: false, ... })`, which resolves cleanly and is handled by `if (!result?.ok)`. This asymmetry also means the CLI test mocks (which use `mockResolvedValueOnce({ ok: false, ... })`) don't match the actual gateway behavior for the `trust` handler.

Make both consistent by using the application-level error pattern:

```suggestion
    if (!result.ok) {
      respond(true, { ok: false, agentId: p.agentId?.trim() || "main", message: result.error }, undefined);
      return;
    }
```

How can I resolve this? If you propose a fix, please make it concise.

Valid issue. The trust handler uses respond(false, ..., errorShape(...)) which throws on the client side, while untrust uses respond(true, { ok: false, ... }) which resolves cleanly. Will switch to the application-level error pattern (respond(true, { ok: false, ... })) for consistency — matches what the CLI expects.

Status: Will fix in next commit.

Filter guild config keys before creating guild-scoped commands

This loop uses raw guildEntries keys as guildId, but Discord guild config keys are not guaranteed to be Snowflake IDs (slug keys are accepted and * defaults are preserved in guild entry resolution). When a slug or * is present, trust/untrust commands are built with invalid guildId values, which can cause slash-command deploy failures and leave the new trust commands unavailable in otherwise valid guild setups.

Useful? React with 👍 / 👎.

Already addressed in commit d79678b. The loop now includes a Snowflake regex filter:

if (!/^\\d{17,20}$/.test(guildId)) {
  continue;
}

This skips slug keys and wildcards. Verified working in production.

Status: ✅ Resolved

Normalize agent IDs before storing trust-window cache keys

Trust windows are keyed by the raw trimmed agentId here, but runtime agent resolution normalizes IDs (including lowercasing) before exec policy checks. If an operator grants trust with mixed-case input (for example --agent MyAgent), exec lookups for myagent miss this cache entry, so the trust window does not actually apply and later revocation with normalized IDs can report no active window.

Useful? React with 👍 / 👎.

Valid concern. Agent IDs should be normalized (lowercased + trimmed) before cache key storage so that --agent MyAgent and runtime lookups for myagent hit the same entry. Will normalize in grantTrustWindow, revokeTrustWindow, getTrustWindow, and the status handler.

Status: Will fix in next commit.

Scope trust audit summaries to the current trust window

summarizeTrustAudit receives startedAt/endedAt from revokeTrustWindow, but it computes totals and command previews from the entire file without filtering by timestamp. If an operator uses --keep (or a previous cleanup fails), the next revoke/expiry summary will include stale commands from earlier windows, so the reported command/failure counts and listed commands are inaccurate for the window being revoked.

Useful? React with 👍 / 👎.

Strengthen trust escalation guard beyond stdin TTY checks

The new self-escalation guard only checks process.stdin.isTTY, which does not prove a human is present. Automated exec sessions can run commands in PTY mode (the exec tool supports pty=true), causing this check to pass and allowing non-interactive callers to run openclaw approvals trust --yes; this bypasses the intended protection against agent-initiated trust grants.

Useful? React with 👍 / 👎.

Reject wildcard allowlists when authorizing trust commands

This owner check accepts allowFrom: ["*"] as authorized because normalizeDiscordAllowList sets allowAll and allowListMatches returns true for any user, so any member who can run slash commands can grant/revoke trust windows and bypass exec approvals. In deployments that use wildcard allowlists for normal chat access, this is a privilege-escalation path and breaks the intended “owner-gated” security model.

Useful? React with 👍 / 👎.

Register trust commands even without explicit guild entries

Trust/untrust commands are only added inside the if (nativeEnabled && guildEntries) block, so accounts with no guilds map (or wildcard-only configs that don’t provide concrete guild keys) never register these commands at all. In those common setups, /trust and /untrust are unavailable despite native commands being enabled.

Useful? React with 👍 / 👎.

Remove stray merge text from exec tool module

The top-level expression feat/trust-windows-v2 (and the following main token) is accidental merge text that gets evaluated when this module loads; in runtime paths that transpile without full type-checking, importing src/agents/bash-tools.exec.ts will throw a ReferenceError before any exec logic runs. This breaks all command execution flows that depend on this module.

Useful? React with 👍 / 👎.

Filter expired trust windows in trust status RPC

exec.approvals.trust.status returns whatever is in getTrustWindow(...) without checking expiresAt, so it can report a window as present/active even after it has already stopped affecting exec policy (the enforcement path only treats it as active while Date.now() < expiresAt). Clients that rely on this RPC can therefore show or act on stale elevated-access state.

Useful? React with 👍 / 👎.

Resolve gateway auth before invoking Discord trust RPCs

callGatewayRpc builds a GatewayClient with only URL and scopes, but never resolves/passes gateway token/password; in token/password auth deployments this backend operator connection is rejected, so /trust and /untrust fail even for authorized owners. The existing Discord exec-approvals path resolves credentials before creating GatewayClient, and this path needs the same auth wiring to work outside insecure/no-auth setups.

Useful? React with 👍 / 👎.

Check untrust RPC result before reporting revocation

This command prints a successful revocation immediately after the RPC call without checking result.ok. The server method returns { ok: false, message } for cases like no active window or invalid agent, so the CLI can report “Trust window revoked” when nothing changed, which misleads operators about the current approval state.

Useful? React with 👍 / 👎.

Count commands that finish after trust-window end

The summary filter excludes any entry with e.ts > endedAt, but trust-audit entries are recorded when command execution completes (the exec hosts append after process completion). Commands started during an active trust window but finishing after expiry/revocation are therefore omitted from the window summary, producing inaccurate command and failure totals.

Useful? React with 👍 / 👎.

Enforce ID-only owner checks for trust commands

isOwnerAuthorized claims trust actions require explicit owner IDs, but it still enables name/tag matching via allowNameMatching. When dangerousNameMatching is turned on and allowFrom contains non-ID entries, another user can match the same normalized name/tag and run /trust or /untrust, which is a privilege-escalation path for this admin operation.

Useful? React with 👍 / 👎.

Check untrust RPC result before confirming revocation

This path always sends a “trust window revoked” reply even when the RPC returns { ok: false, message } (for example, no active window or invalid agent). Because the handler does not branch on result.ok, operators can get a false-success confirmation while the trust state remains unchanged.

Useful? React with 👍 / 👎.

Apply node trust override before deny check

executeNodeHostCommand calls resolveExecHostApprovalContext before evaluating trustWindowActive, but the shared resolver throws immediately when host security resolves to deny (src/agents/bash-tools.exec-host-shared.ts). In node-host setups that intentionally default to security=deny, an active trust window never gets a chance to elevate to full/off, so trusted sessions still fail with exec denied instead of honoring the new trust-window feature.

Useful? React with 👍 / 👎.

Ignore stale trust-status responses after agent switches

refreshTrustWindow requests status with the current agentId but then unconditionally writes trustWindow/trustWindowFetchedAt when the promise resolves. If the user switches agents while that request is in flight, the old response overwrites the cache for the new agent, and the 30s throttle suppresses a fresh fetch, so the footer can show the wrong trust state for up to 30 seconds.

Useful? React with 👍 / 👎.