openclaw - 💡(How to fix) Fix [Feature]: allow explicit config unset to bypass size-drop guard for intentional large deletes [1 pull requests]

Summary

Add an explicit openclaw config unset option that allows an intentional large config deletion to bypass only the size-drop:* guard while keeping other destructive-write protections active.

Problem to solve

openclaw config unset <path> is an explicit delete operation, but it can currently be rejected when the resulting openclaw.json is less than 50% of the original file size.

This is still reproducible on OpenClaw 2026.5.12 (f066dd2). In that version, openclaw config unset --help only exposes the required <path> argument and -h, --help; there is no --force, --allow-size-drop, or equivalent opt-in.

The current behavior is insufficient because a legitimate large node, such as models.providers.<provider-id>, can make up more than half of the config. Removing that node with config unset models.providers.<provider-id> is intentional, but the write is rejected as if it were an accidental clobber.

Proposed solution

Add an explicit opt-in flag for config unset.

Possible names:

• openclaw config unset --allow-size-drop <path>
• openclaw config unset --force <path>

The exact flag name can follow maintainer preference. The important behavior is that the flag is narrow:

• It only bypasses size-drop:*.
• It does not bypass gateway-mode-removed or other hard destructive-write guards.
• It requires the target path to exist, preserving the current missing-path behavior.
• It preserves schema validation for the resulting config.
• It keeps the delete intent represented through unsetPaths.
• The default no-flag behavior remains unchanged and continues rejecting suspicious large drops.

Alternatives considered

One alternative is to edit openclaw.json directly from integrations that need to remove a large provider. That is weaker because it bypasses OpenClaw CLI validation, audit/rejected-artifact behavior, and config write protections.

Another alternative is to use a broader destructive-write override. That is weaker because it risks weakening protections that should remain hard-blocked, especially cases such as gateway-mode-removed.

Another alternative is to keep the current behavior and require users to manually shrink config in smaller steps. That creates extra manual work and does not give automation a safe, explicit way to express an intentional large unset.

Impact

Affected users/systems/channels:

• Users and integrations that manage OpenClaw configuration through the public CLI.
• Provider/model configuration workflows that remove large entries under models.providers.<provider-id>.
• Automation that relies on config unset rather than direct JSON file edits.

Severity:

• Blocks workflow for affected delete operations. The CLI rejects the intended write, leaves the original config unchanged, and returns a non-zero exit status.

Frequency:

• Edge case, but deterministic when the removed node causes the serialized config to drop below the current size-drop threshold.

Consequence:

• Legitimate config removal fails.
• Integrations must either leave stale config in place, ask users to do manual cleanup, or consider unsafe direct JSON edits.
• The rejected payload is saved, but there is no supported CLI path to complete the intentional unset safely.

Evidence/examples

This reproduction uses an isolated synthetic OPENCLAW_HOME and OPENCLAW_CONFIG_PATH. It does not touch a live OpenClaw config, and it does not include a real provider name, host, request id, job id, API key, or production config.

tmp="$(mktemp -d)"
config="$tmp/openclaw.json"

node - "$config" <<'NODE'
const fs = require('fs');
const target = process.argv[2];
const models = Array.from({ length: 40 }, (_, index) => ({
  id: `model-${index}`,
  name: `Model ${index}`,
  contextWindow: 200000,
  maxTokens: 8192,
  cost: { cacheRead: 0, cacheWrite: 0, input: 0, output: 0 },
  input: ['text'],
  reasoning: false,
}));

const config = {
  meta: { lastTouchedVersion: '2026.5.12' },
  gateway: { mode: 'local' },
  models: {
    providers: {
      'synthetic-large-provider': {
        api: 'openai-completions',
        baseUrl: 'https://example.invalid/v1',
        apiKey: 'redacted-test-key',
        models,
      },
    },
  },
  agents: {
    defaults: {
      models: Object.fromEntries(
        models.map((model) => [`synthetic-large-provider/${model.id}`, {}]),
      ),
    },
  },
};

fs.writeFileSync(target, `${JSON.stringify(config, null, 2)}\n`);
NODE

before="$(wc -c < "$config")"

HOME="$tmp" \
OPENCLAW_HOME="$tmp" \
OPENCLAW_CONFIG_PATH="$config" \
openclaw config unset models.providers.synthetic-large-provider

after="$(wc -c < "$config")"
printf 'before=%s after=%s\n' "$before" "$after"
find "$tmp" -maxdepth 1 -name 'openclaw.json.rejected.*' -print

Observed result on 2026.5.12 (f066dd2):

OpenClaw version: OpenClaw 2026.5.12 (f066dd2)
exit status: 1
before bytes: 18138
after bytes: 18138
Config write rejected: <tmp>/openclaw.json (size-drop:18138->2204).
Rejected payload saved to <tmp>/openclaw.json.rejected.<timestamp>.

The original config remains unchanged, and a .rejected.* artifact is created.

Duplicate check:

• I did not find an exact existing issue/PR for models.providers large-node config unset being blocked by size-drop.
• I did not find an existing config unset option that exposes allowConfigSizeDrop or an equivalent force-like opt-in.

Related but not duplicate:

• #71865: size-drop guard false positive around a PowerShell/BOM/verbose-format auth-login case.
• #79549: preserves absent keys on partial writes and requires unsetPaths for deletion, but does not expose a size-drop override for config unset.
• #79299 / #80257: related config clobber/data-loss protection work, but not this explicit large-unset CLI affordance.

Searches checked:

• repo:openclaw/openclaw "config unset" "size-drop" in:title,body
• repo:openclaw/openclaw "models.providers" "size-drop" in:title,body
• repo:openclaw/openclaw "unset --force" in:title,body
• repo:openclaw/openclaw "allowConfigSizeDrop" "unset" in:title,body
• repo:openclaw/openclaw "Config write rejected" "config unset" in:title,body

Additional information

This request is not asking OpenClaw to weaken the default clobber guard. It asks for a narrow, explicit affordance for intentional large deletes through the public CLI.

If maintainers agree with the direction, a focused PR could:

• Add the selected flag to config unset.
• Pass allowConfigSizeDrop: true into config write options only when that flag is present.
• Keep default config unset behavior unchanged.
• Add regression coverage for default rejection, explicit allowed size-drop, and gateway-mode-removed still being blocked.

This issue was prepared with Codex assistance and manually checked against an isolated local OpenClaw 2026.5.12 (f066dd2) reproduction.