Bug: Config file concurrent write race truncates openclaw.json
What happened
When the Gateway daemon and a CLI tool (or two Gateway processes) write ~/.openclaw/openclaw.json concurrently, the file can be truncated to ~61 bytes, corrupting the entire configuration and causing service interruption.
Environment
- OpenClaw: 2026.5.28 (e932160)
- OS: Windows 10.0.26200 (x64)
- Node: v24.16.0
Reproduction
- Have Gateway running (it writes config on hot-reload/restart)
- Trigger a CLI config write at the same time (e.g., openclaw config patch or a gateway tool call from an agent session)
- Observe openclaw.json truncated to ~61 bytes
This has been observed at least twice in production use.
Root cause analysis
The config write uses an atomic-write pattern (write temp, fsync, rename), but there is no file-level locking to prevent two writers from racing. When both writers read the file at nearly the same time, one write overwrites the other's changes. In worst case, the temp file rename races with a read, producing a truncated file.
The missing-meta-before-write log entries on every config read suggest the meta field is stripped during reads, compounding the data loss.
Suggested fix
Add a proper file lock (e.g., proper-lockfile npm package) around all config read-modify-write operations in both the Gateway daemon and CLI tools. The lock should be:
- Acquired before reading the config file
- Held through the entire read-modify-write cycle
- Released after the atomic rename completes
Impact
- Severity: P0 — complete config loss, service interruption
- Frequency: Rare but reproducible under concurrent access
- Affected: All platforms (observed on Windows, likely affects Linux/macOS too)
Bug: Config file concurrent write race truncates openclaw.json
What happened
When the Gateway daemon and a CLI tool (or two Gateway processes) write ~/.openclaw/openclaw.json concurrently, the file can be truncated to ~61 bytes, corrupting the entire configuration and causing service interruption.
Environment
Reproduction
This has been observed at least twice in production use.
Root cause analysis
The config write uses an atomic-write pattern (write temp, fsync, rename), but there is no file-level locking to prevent two writers from racing. When both writers read the file at nearly the same time, one write overwrites the other's changes. In worst case, the temp file rename races with a read, producing a truncated file.
The missing-meta-before-write log entries on every config read suggest the meta field is stripped during reads, compounding the data loss.
Suggested fix
Add a proper file lock (e.g., proper-lockfile npm package) around all config read-modify-write operations in both the Gateway daemon and CLI tools. The lock should be:
Impact