Summary

After side-by-side cutover, the live gateway service was running from the sidecar tree and reporting 2026.4.14, but openclaw logs --follow still showed 2026.3.28-beta.1 and tailed repeated old warning lines from the rolling log file. This was operationally misleading during incident/debugging.

Observed behavior

Live systemd gateway service:

• ExecStart=/usr/bin/node /home/claw/openclaw-sidecar-2026-04-14/dist/index.js gateway --port 18789
• live gateway app version: 2026.4.14

But openclaw logs --follow output showed:

• OpenClaw 2026.3.28-beta.1 (50bc870)
• then tailed /tmp/openclaw/openclaw-2026-04-14.log
• output was dominated by repeated:
  • Config was last written by a newer OpenClaw (2026.4.12); current version is 2026.3.28-beta.1.

Operational workaround during the incident was:

• journalctl --user -u openclaw-gateway.service -f

Why this is a bug

The command appears to promise live OpenClaw logs. In practice it can show stale or version-mismatched file-log output. This is especially misleading during cutover, split-install, or recovery situations.

Source-backed likely root cause

Current implementation source:

• src/cli/logs-cli.ts

Notable details:

• the command is described as: Tail gateway file logs via RPC
• it calls RPC method logs.tail
• if RPC fails / pairing is required on local loopback, it falls back to local file-tail behavior
• that fallback is not active-service aware

So after side-by-side cutover it can follow configured rolling file logs from an old CLI/install context rather than the authoritative current service journal.

Repro steps

1. Start from a system where OpenClaw CLI and gateway service both point at an older install tree.
2. Build a newer side-by-side tree separately.
3. Cut over the systemd gateway service only, so the live service points at the sidecar tree and reports a newer version.
4. Leave the CLI path still pointing at the old install tree.
5. Run:
   • openclaw logs --follow
6. Observe that the command can report the old CLI/runtime version and follow rolling file logs that do not accurately represent the live gateway service context.
7. Compare with:
   • journalctl --user -u openclaw-gateway.service -f

Actual behavior

• openclaw logs --follow can show stale or version-mismatched old-version file-log output after side-by-side cutover.
• It does not clearly disclose that the tailed source is a file-log fallback rather than the active service journal.

Expected behavior

• openclaw logs --follow should follow the active gateway service logs on Linux when possible.
• If it must fall back to a file tail, it should say so clearly and warn when the tailed source may not represent the live service.

Requested fix

Please do both:

1. On Linux, make openclaw logs --follow prefer the active systemd service journal when available.

   • effectively treat the active openclaw-gateway.service journal as the source of truth

2. Before following any source, print explicit provenance:

   • CLI version
   • active service ExecStart
   • active service PID
   • exact log source being tailed
   • mismatch warning if CLI version, service version, or tailed log source do not agree

Proposed Linux/systemd behavior

In systemd environments, prefer the current openclaw-gateway.service journal as the authoritative live-log source.
Only use rolling file-tail fallback when service-aware log access is unavailable, and make that fallback explicit in output.