toggling Send User-Agent silently removes every unrelated custom header - cc-switch
Quick fix
Do not toggle Send User-Agent in the OpenClaw provider editor; upgrade and wait for a fix, as the switch replaces or deletes the entire headers object.
Symptom
Section titled “Symptom”enabling leaves only the default User-Agent header; disabling or an on/off round trip removes `headers` entirelyIn the cc-switch OpenClaw provider editor, the Send User-Agent switch does not only add or remove that request header. It destructively updates the entire headers object: enabling it replaces headers with an object containing only the default User-Agent, while disabling it deletes the entire headers object. The loss also occurs if you turn the switch on and then off before saving; the damaged configuration is carried into the final form submission. The problematic code is in the destructive header update logic in useOpenclawFormState.ts (L160-L169), which writes the form configuration through ProviderForm.tsx and into the submission payload. The issue author reproduced this offline with jsdom against the 3.20.4 source (commit bfaaba16): 6 of 14 diagnostic tests failed preservation checks (enable, disable, and round-trip each failed at both the hook and final submission layers); 8 control tests passed, including saving without touching the switch, enabling when headers were absent, removing only User-Agent, and confirming non-header fields were unaffected. The hook was byte-for-byte identical on the then-current main branch (commit 372b1698), so the same issue also existed there. The issue is closed, but the report does not specify a fixed version. The author's suggested fix is to merge the default User-Agent into existing headers when enabling, and when disabling, remove only User-Agent and delete the entire object only if headers becomes empty.
Until a fixed version is released, do not touch the Send User-Agent switch when editing an OpenClaw provider. If you leave it alone, opening and saving directly preserves existing custom request headers; the issue's control tests confirmed this path is lossless.
If you already toggled the switch and lost headers, manually restore the deleted custom request headers in the provider configuration (such as X-Fixture and X-Other). After saving, avoid toggling the switch again.
Upgrade to a cc-switch version that includes the fix. The correct behavior suggested by the issue author is to merge the default User-Agent into existing headers when enabling, and remove only User-Agent when disabling, deleting the entire object only if headers is empty. After upgrading, verify with a non-critical provider configuration that custom request headers remain after toggling the switch on and off.
Affected Versions
Section titled “Affected Versions”Source Issues
Section titled “Source Issues”This page is distilled from 1 real issues
- Will custom request headers be lost if I only open the editor and save without touching this switch?
- No. The issue's control tests confirmed that hydration and saving without touching the switch preserve the original headers; loss occurs only when enabling, disabling, or turning it on and then off.
- Does this bug affect configuration fields outside headers?
- No. The 8 passing control tests included a check that non-header configuration fields were preserved. Only the headers object is affected.
- Is there a problem enabling this switch if the configuration originally had no custom request headers?
- No. The control tests covered enabling when headers were absent, and that path passed. Existing custom request headers are the ones that get overwritten and lost.
Related problems
Section titled “Related problems”This is an unofficial community wiki with no affiliation to the cc-switch authors or the project itself. Its content is compiled from the project's public GitHub issues. This site distributes no software.