Bug Description

openclaw logs --follow connects through the gateway websocket layer and registers as a full paired device, causing paired.json rewrites and contributing to file read race conditions.

Steps to Reproduce

1. Check paired.json state: stat ~/.openclaw/devices/paired.json
2. Note the inode and modify timestamp
3. Run openclaw logs --follow
4. Check paired.json again: stat ~/.openclaw/devices/paired.json
5. Observe inode changed (temp-file + rename write pattern)

Expected Behavior

openclaw logs --follow should behave like a passive log reader (tail -F), not as a full gateway client. It should:

• NOT register in paired.json
• NOT trigger device state updates
• Use a lightweight "observer" mode with read-only access to logs

Actual Behavior

• openclaw logs --follow registers as a device with clientMode: cli and operator.write scope
• Every connection triggers a paired.json rewrite (inode change observed)
• Contributes to file read races when other components read during rewrite
• Has operator.write scope despite being a log reader

Environment

• OpenClaw version: 2026.5.12
• OS: Ubuntu 24.04.4 LTS
• paired.json entries: 4 (2 stale, 36-47 days old)

Related Issues

• paired_devices.createdAt / lastSeenAt are null — cannot identify stale paired clients #81169 — paired.json stale entry accumulation and read races
• [Bug]: Gateway data loss: Silent read error on paired.json leads to overwrite of all pairings #71873 — Silent read error on paired.json (same underlying fragility)

Recommendation

Add a CLI "observer" mode that:

1. Connects to gateway websocket for log streaming
2. Does NOT write to paired.json
3. Does NOT participate in device/session activity
4. Has minimal scope (read-only log access)

Or alternatively: make openclaw logs --follow use direct file tailing instead of websocket connection.