T-ACCESS-003: plaintext token storage validated, hardening PR submitted

[Techris93]

Summary

Validated T-ACCESS-003 (Token Theft) against a local gateway instance.
The residual risk "tokens stored in plaintext" is confirmed — the full
48-character hex auth token is readable in ~/.openclaw/openclaw.json
via a simple grep.

Reproduction

grep -i token ~/.openclaw/openclaw.json
# Output: "token": "<full 48-char hex token visible in plaintext>"

[Techris93]

File permissions are 0o600 (owner-only), which is the only current mitigation. However:

Tokens appear in plaintext in CLI output and log files
If the config directory is inside a git repo, tokens can be accidentally committed and pushed to a remote
There is no rotation mechanism — a compromised token stays valid indefinitely

Proposed Mitigations (PR submitted)

I've submitted a hardening PR to openclaw/openclaw with three standalone modules:

• token-redactor.ts — Wraps console output methods to redact tokens from logs. Covers JSON fields, util.inspect format, and Bearer headers. Includes install/uninstall for test compatibility.

• git-config-guard.ts — Walks up from the config directory at startup looking for .git. Warns if found, with a correct .gitignore entry suggestion (handles Windows paths and edge cases).

• token-rotation.ts — Generates a new cryptographic token and atomically replaces the old one using write-to-temp-then-rename with exclusive lockfile protection. Enforces 0o600 via chmodSync.

PR: https://github.com/Techris93/openclaw/pull/32373

Trust Model Alignment

These are defense-in-depth improvements, not security boundary changes. Operators remain trusted. Keychain integration (macOS Keychain / libsecret) was deliberately excluded pending maintainer input on dependency policy.

Environment

• OpenClaw: latest main (cloned fresh)
• OS: macOS + Kali Linux
• Node.js: v22.12.0+