Summary

exec-approvals.json appears to ignore the configured OpenClaw state/config root in some installs, and is persisted under user home (~/.openclaw) instead of the active runtime root (/var/lib/openclaw in this case).

Environment

• OpenClaw: 2026.2.26
• Host: Linux (systemd gateway service)
• Runtime/config appears rooted under /var/lib/openclaw (sessions/config/channels active there)

Observed behavior

After approving exec prompts with Always allow, approvals are written to:

• /home/gord/.openclaw/exec-approvals.json

Confirmed by CLI:

openclaw approvals get --json

Response includes:

{
  "path": "/home/gord/.openclaw/exec-approvals.json",
  "exists": true,
  ...
}

Expected behavior

When OpenClaw is running from a configured state root under /var/lib/openclaw, exec approvals should be stored in that same state root (or at least follow the same resolved state-dir semantics as other runtime artifacts), not silently split into ~/.openclaw.

Why this is problematic

• Surprising split-brain state (/var/lib/openclaw vs ~/.openclaw)
• Harder backup/migration/ops consistency
• Potential confusion across service/user contexts

Repro

1. Run OpenClaw service with active runtime/config under /var/lib/openclaw
2. Trigger an exec approval prompt
3. Click Always allow
4. Run openclaw approvals get --json
5. Observe path resolves to ~/.openclaw/exec-approvals.json

Additional context

A related historical issue exists for identity path behavior ignoring state dir:

• Device identity ignores OPENCLAW_STATE_DIR, always writes to ~/.openclaw/identity #9866

This may be the same class of path-resolution bug for approvals.