Summary
Over the past few issues (for example #9627, #11268, #4654), there seems to be a recurring pattern where openclaw doctor --fix or other config-writing commands modify user configuration in ways that are difficult to recover from. In some cases, environment variables are resolved into plaintext, or redacted placeholders end up written into the actual config file.
Right now, running doctor --fix can permanently change a working configuration without giving users a safe preview of what will be modified. This creates unnecessary risk, especially when secrets and authentication settings are involved.
I think there’s an opportunity to make this workflow safer and more predictable.
Proposed solution
Introduce a --dry-run flag for openclaw doctor.
When a user runs:
openclaw doctor --dry-run
the command would perform all validation and generate the same fix recommendations, but it would never write anything to disk. It would simply show what would change and exit with a non-zero code if issues are found.
Users could then review the output and explicitly run:
openclaw doctor --fix
if they’re comfortable applying the changes.
This would add a safety layer without changing existing behavior, and it would align with how many CLI tools handle potentially destructive operations.
If this sounds reasonable, I’d be happy to work on a draft PR.
Alternatives considered
One alternative would be to require confirmation prompts before applying fixes. However, prompts alone don’t fully solve the issue, especially in CI environments or when --yes is used.
Another approach could be automatic backups only, but that still doesn’t give users visibility into what will change before it happens.
A dry-run mode feels like the most transparent and flexible option.
Additional context
Related issues:
#9627 #11268 #4654
This proposal is mainly about preventing accidental config corruption and improving user trust in the CLI workflow.
Summary
Over the past few issues (for example #9627, #11268, #4654), there seems to be a recurring pattern where openclaw doctor --fix or other config-writing commands modify user configuration in ways that are difficult to recover from. In some cases, environment variables are resolved into plaintext, or redacted placeholders end up written into the actual config file.
Right now, running doctor --fix can permanently change a working configuration without giving users a safe preview of what will be modified. This creates unnecessary risk, especially when secrets and authentication settings are involved.
I think there’s an opportunity to make this workflow safer and more predictable.
Proposed solution
Introduce a --dry-run flag for openclaw doctor.
When a user runs:
openclaw doctor --dry-runthe command would perform all validation and generate the same fix recommendations, but it would never write anything to disk. It would simply show what would change and exit with a non-zero code if issues are found.
Users could then review the output and explicitly run:
openclaw doctor --fixif they’re comfortable applying the changes.
This would add a safety layer without changing existing behavior, and it would align with how many CLI tools handle potentially destructive operations.
If this sounds reasonable, I’d be happy to work on a draft PR.
Alternatives considered
One alternative would be to require confirmation prompts before applying fixes. However, prompts alone don’t fully solve the issue, especially in CI environments or when --yes is used.
Another approach could be automatic backups only, but that still doesn’t give users visibility into what will change before it happens.
A dry-run mode feels like the most transparent and flexible option.
Additional context
Related issues:
#9627 #11268 #4654
This proposal is mainly about preventing accidental config corruption and improving user trust in the CLI workflow.