Let untrust handle expired trust windows

This early return makes revokeTrustWindow fail as soon as a window has naturally expired, so exec.approvals.untrust never reaches its audit cleanup path (cleanupTrustAudit(...) in src/gateway/server-methods/exec-approvals.ts). In practice, if an operator runs untrust after expiry, the CLI just reports “No active trust window” and the trust audit file cannot be removed via the supported untrust workflow, while expired cache entries remain until restart; expired windows should still be treated as revocable for cleanup purposes.

Useful? React with 👍 / 👎.

Dead "No active trust window" error path in untrust catch block

This error branch can no longer be triggered. Prior to this PR the server returned a "No active trust window" error when untrust was called with no active window; the CLI swallowed that particular error and treated it as success. The updated server handler now passes allowMissing: true to revokeTrustWindow, so the gateway always responds with ok: true (never an error) when the window is simply absent. The string-match check is dead code that could mislead future maintainers into thinking this error path is still live.

This is a comment left during a code review.
Path: src/cli/exec-approvals-cli.ts
Line: 604-608

Comment:
**Dead "No active trust window" error path in `untrust` catch block**

This error branch can no longer be triggered. Prior to this PR the server returned a "No active trust window" error when `untrust` was called with no active window; the CLI swallowed that particular error and treated it as success. The updated server handler now passes `allowMissing: true` to `revokeTrustWindow`, so the gateway always responds with `ok: true` (never an error) when the window is simply absent. The string-match check is dead code that could mislead future maintainers into thinking this error path is still live.

```suggestion
      } catch (err) {
        defaultRuntime.error(formatCliError(err));
        defaultRuntime.exit(1);
      }
```

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

trust-status CLI command missing agent session guard

trust has both a TTY check and an OPENCLAW_SESSION_KEY/OPENCLAW_AGENT_ID env-var check. untrust has the env-var check. trust-status has neither. An agent process that has access to the CLI binary (and whose env vars are not set) can run openclaw approvals trust-status from within a session and learn whether a trust window is active for its agent ID, because the server's isTrustGrantCallerAllowed will see a legitimate CLI connection and allow it through.

While knowing the trust status doesn't directly enable further escalation (the agent's exec calls are already permitted or denied by the approval layer), it is inconsistent with the "no agent self-escalation" design and lets an agent adapt its behavior based on observed trust state. Consider adding at minimum the env-var guard:

.action(async (opts: TrustStatusOpts) => {
  try {
    if (process.env.OPENCLAW_SESSION_KEY || process.env.OPENCLAW_AGENT_ID) {
      exitWithError(
        "Trust status queries are blocked from agent sessions. Use a direct terminal session.",
      );
    }
    // ... rest of handler

This is a comment left during a code review.
Path: src/cli/exec-approvals-cli.ts
Line: 629-656

Comment:
**`trust-status` CLI command missing agent session guard**

`trust` has both a TTY check and an `OPENCLAW_SESSION_KEY`/`OPENCLAW_AGENT_ID` env-var check. `untrust` has the env-var check. `trust-status` has neither. An agent process that has access to the CLI binary (and whose env vars are not set) can run `openclaw approvals trust-status` from within a session and learn whether a trust window is active for its agent ID, because the server's `isTrustGrantCallerAllowed` will see a legitimate CLI connection and allow it through.

While knowing the trust status doesn't directly enable further escalation (the agent's exec calls are already permitted or denied by the approval layer), it is inconsistent with the "no agent self-escalation" design and lets an agent adapt its behavior based on observed trust state. Consider adding at minimum the env-var guard:

```typescript
.action(async (opts: TrustStatusOpts) => {
  try {
    if (process.env.OPENCLAW_SESSION_KEY || process.env.OPENCLAW_AGENT_ID) {
      exitWithError(
        "Trust status queries are blocked from agent sessions. Use a direct terminal session.",
      );
    }
    // ... rest of handler
```

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

Temp directory not cleaned up in afterEach

homeDir is populated by makeTempDir() in beforeEach but afterEach only restores the OPENCLAW_HOME env var — it never removes the temp directory itself. Compare with the existing cleanup pattern used in exec-approvals.test.ts:

} finally {
  process.env.OPENCLAW_HOME = previousHome;
  fs.rmSync(homeDir, { recursive: true, force: true });
}

Each test run leaks a temp directory. Add fs.rmSync(homeDir, { recursive: true, force: true }) to the afterEach hook:

This is a comment left during a code review.
Path: src/infra/trust-audit.test.ts
Line: 22-35

Comment:
**Temp directory not cleaned up in `afterEach`**

`homeDir` is populated by `makeTempDir()` in `beforeEach` but `afterEach` only restores the `OPENCLAW_HOME` env var — it never removes the temp directory itself. Compare with the existing cleanup pattern used in `exec-approvals.test.ts`:

```typescript
} finally {
  process.env.OPENCLAW_HOME = previousHome;
  fs.rmSync(homeDir, { recursive: true, force: true });
}
```

Each test run leaks a temp directory. Add `fs.rmSync(homeDir, { recursive: true, force: true })` to the `afterEach` hook:

```suggestion
  afterEach(() => {
    process.env.OPENCLAW_HOME = previousHome;
    if (homeDir) {
      fs.rmSync(homeDir, { recursive: true, force: true });
    }
  });
```

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

Audit trusted commands in gateway approval-followup path

This trust-audit append is only reached for the synchronous run.promise path, so commands that execute via processGatewayAllowlist(...).pendingResult are never logged. That path is still reachable during an active trust window when requiresAsk is forced (for example by obfuscation detection), which means successful trusted-window executions can be omitted from the trust audit and revoke summary.

Useful? React with 👍 / 👎.

Audit trusted commands in node approval-followup path

In executeNodeHostCommand, trust auditing is only appended in the non-approval branch here; when requiresAsk is true (which can still happen under trust, e.g. obfuscation-triggered approvals), execution continues through the async followup flow and never reaches this write. The result is missing trust-audit entries for commands that did run during the trust window.

Useful? React with 👍 / 👎.

Keep node trust runs from dropping the approval signal

When a trust window is active this branch forces hostAsk to "off", which makes executeNodeHostCommand skip the gateway approval flow and call node.invoke with approved=false; on node-hosts using the default allowlist/on-miss policy, evaluateSystemRunPolicy then rejects the run as SYSTEM_RUN_DENIED: approval required. I checked this path in src/agents/bash-tools.exec-host-node.ts (direct buildInvokeParams(false, null) call) and src/node-host/exec-policy.ts, so trusted node commands can still fail even though trust is reported active.

Useful? React with 👍 / 👎.