[johan456789]

Summary

The CLI can store an API key (config set-api-key) but has no way to store a manual cookie or to remove a stored credential. Settings can do both, so on macOS this only matters for scripting. On Linux, where there is no app and browser cookie import is unavailable, manual cookies are the only way to use cookie providers, and today the only route is hand-editing config.json.

This PR adds the two missing commands, modeled on set-api-key (#978) and set-source:

pbpaste | codexbar config set-cookie --provider claude --stdin
codexbar config clear-credential --provider claude            # API key and manual cookie
codexbar config clear-credential --provider claude --cookie   # only the cookie
codexbar config clear-credential --provider openrouter --api-key

config set-cookie

config set-cookie --provider <name> (--cookie <header>|--stdin) [--no-enable]

• Writes cookieHeader and sets cookieSource: manual, the same two fields Settings writes when you paste a manual cookie (SettingsStore+Config.swift).

• Trims input, rejects empty and multi-line values, and rejects --cookie together with --stdin.

• Enables the provider by default (--no-enable to opt out), like set-api-key.

• Output never contains the cookie. JSON is {provider, enabled, configPath}, matching set-api-key.

• Only providers that actually read a config cookie are accepted, in the spirit of Add config API key CLI #978's "only accepts consumed config keys". A provider qualifies if its fetch plan offers the web source (the same descriptor data set-source validates against), or if its credential adapter projects the config cookie into the fetch environment. DeepSeek is the one case today: it stores its platform token in cookieHeader. Everything else gets <name> does not support config cookies. and the config is not touched.

  At this commit 50 provider IDs qualify. A test checks every registered alias against the rule.

config clear-credential

config clear-credential --provider <name> [--api-key] [--cookie]

• Without flags it removes both apiKey and cookieHeader. --api-key or --cookie limits it to one.
• Clearing a cookie also resets a manual cookieSource to the provider default, since a manual source with no header has nothing to send. Non-manual sources (for example off) are kept.
• Clearing Moonshot's API key also drops its key-bound apiKeyRegion, matching MoonshotSettingsStore.
• Enablement, source, token accounts, and all other fields are left alone. Removing token accounts is out of scope here.
• Accepts any known provider. Clearing is always safe, including legacy keys such as DeepSeek's old apiKey.
• When nothing is stored, it writes nothing (a missing config file stays missing) and reports an empty cleared list. JSON is {provider, cleared: ["apiKey", "cookieHeader"], configPath}.

Commits

1. feat(cli): add config set-cookie for manual cookies
2. feat(cli): add config clear-credential to remove stored credentials

Each commit adds its command, help text, docs (docs/cli-configuration.md, docs/cli.md, plus a pointer in the manual-cookie section of docs/configuration.md), a CHANGELOG line under 0.81.1, and tests. Both commands are also added to the existing CLICommonOptionsTests path list and the CLIPluginConfigPreservationTests matrix.

Commands run (Linux, x86_64, Swift 6.4)

• swift build --product CodexBarCLI: clean.
• CLIConfigCookieCommandTests, CLIConfigClearCredentialCommandTests, CLIConfigCommandTests, CLIConfigSourceCommandTests, CLICommonOptionsTests: 42 tests passed. CodexBarTests is macOS-only, so I ran these by temporarily copying the files into TestsLinux with a Linux TestBuildProducts path. The copies are not committed.
• swift test (full CodexBarLinuxTests): everything passes except 4 tests in PlatformGatingTests (Claude auto pipeline, OpenCodex log URL). These fail identically on unmodified main (d34fbb47a) on this machine, so they come from the local environment and are unrelated.
• ./Scripts/lint.sh lint-linux: 0 violations in 3116 files.
• Manual runs of the real binary against a scratch CODEXBAR_CONFIG:
  • stdin set, then clear, of a Claude cookie
  • rejection for elevenlabs
  • no-op clear leaving the file byte-identical
  • unknown/plugin provider records surviving both commands unchanged (the CLIPluginConfigPreservationTests scenario, which does not compile on Linux)
  • file mode stays 0600

Not run

• macOS: make test/make check, and CLIPluginConfigPreservationTests (needs the macOS test target). PR CI covers these.

Notes for review

• The cookie gate uses the fetch plan's web source instead of a provider's cookie-settings reader. I tried the reader first, but it is not wired for every provider (Claude builds its own settings section, for example), so it would wrongly reject providers that do read manual cookies.
• Providers that also support cookie token accounts still accept a provider-level cookie here. ProviderCookieSettingsResolver uses the config header when no token account is selected. Adding token-account entries from the CLI would be a separate change.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

ClawSweeper review complete

ClawSweeper finished reviewing this revision. The review result is being finalized.

View the workflow run.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	🔄 Running since 2026-10-25T04:00:41.401284Z	d082852	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[clawsweeper]

Codex review: blocked before merge.

What this changes

Adds CLI commands to save manual provider cookies and selectively clear saved API keys or cookies.

Example: Configure a Claude cookie from a Linux terminal.

• Before: The user must edit cookieHeader and cookieSource in config.json.
• After: Piping sessionKey=PLACEHOLDER into config set-cookie --provider claude --stdin saves the cookie and selects manual mode.

Review scores

Measure	Result	What it means
Overall readiness	🦐 gold shrimp (3/6)	Inspectible CLI and upgrade proof now supports the change, but a concrete provider-capability defect and unresolved product direction prevent approval.
Proof confidence	🦞 diamond lobster (5/6)	Sufficient (terminal): The contributor's Linux terminal transcript exercises both real CLI commands against isolated configuration, demonstrating set/clear, unsupported-provider rejection, no-op clearing, private permissions, and preservation of unrelated v0.81.0 settings; it resolves the earlier missing-output request.
Patch quality	🦐 gold shrimp (3/6)	1 actionable review finding remain.

Product

Kind: Feature · Worth it: Needs a maintainer decision · Fix scope: Partial
User problem: CLI users must hand-edit configuration to save manual cookies or remove provider-level credentials.
Reason: The scripting benefit is concrete, especially without the macOS app, but the new command contract needs owner direction and currently excludes an existing cookie consumer.

Merge readiness

⛔ Blocked before merge - 2 items remain

Keep open for an owner decision on the new commands and repair of the cookie-support gate.

Priority: P2
Reviewed head: d0828525d547e26fd248720d5e191fbe18358e40
Owner decision: Required. See Decision needed.

Decision needed

• Question: Should CodexBar add these two credential-management commands with enable-on-set and manual-source reset-on-clear semantics?
• Recommendation: Approve the command direction: Adopt the proposed CLI interface after the capability-gate defect is repaired.
• Why: The commands provide useful scripting support, but no recorded owner approval establishes this new CLI contract; contributor explanations and approval of earlier commands do not settle it.

Before merge

• Recognize settings-backed manual-cookie consumers (P2) - Running codexbar config set-cookie --provider augment --cookie 'session=fixture' fails with “augment does not support config cookies.” Augment advertises only auto/cli and has no environment projections, so both checks here return false. However, its descriptor registers AugmentProviderSettings as cookie settings, and AugmentStatusFetchStrategy passes the configured manual header to AugmentStatusProbe. This prevents the new command from replacing manual config editing for a supported consumer. Include the existing typed cookie-settings registration in capability detection and add an independent Augment regression case. This concern was missed in the earlier review; the affected code is unchanged from that reviewed head.
• Resolve maintainer decision - Resolve the maintainer decision shown above before merge.

Findings

• [P2] Recognize settings-backed manual-cookie consumers — Sources/CodexBarCLI/CLIConfigCookieCommand.swift:59-67

Tests

• Missing end-to-end proof: Add an independent regression case showing that set-cookie accepts Augment and persists the manual cookie through its existing settings registration.

Agent review details

How this fits together

The CLI validates provider arguments and updates the shared configuration store, whose credential fields feed provider settings and fetchers.

flowchart LR
  A[CLI arguments and stdin] --> B[Provider capability validation]
  B --> C[Credential config mutation]
  C --> D[Shared private config store]
  D --> E[Provider settings snapshot]
  E --> F[Provider fetcher]

Loading

Technical review

Best possible solution:

Extend the descriptor-driven cookie gate to recognize existing settings-backed consumers such as Augment while retaining the shared config store and selective clearing behavior.

Do we have a high-confidence way to reproduce the issue?

Source inspection establishes that set-cookie rejects Augment: its advertised sources omit web and its credential adapter projects no environment value, although its settings-backed fallback consumes manual cookies.

Is this the best way to solve the issue?

Reusing the shared config store is appropriate, but advertised source modes and environment projection alone do not establish whether a provider consumes config cookies.

Full review comments:

• [P2] Recognize settings-backed manual-cookie consumers — Sources/CodexBarCLI/CLIConfigCookieCommand.swift:59-67
  Running codexbar config set-cookie --provider augment --cookie 'session=fixture' fails with “augment does not support config cookies.” Augment advertises only auto/cli and has no environment projections, so both checks here return false. However, its descriptor registers AugmentProviderSettings as cookie settings, and AugmentStatusFetchStrategy passes the configured manual header to AugmentStatusProbe. This prevents the new command from replacing manual config editing for a supported consumer. Include the existing typed cookie-settings registration in capability detection and add an independent Augment regression case. This concern was missed in the earlier review; the affected code is unchanged from that reviewed head.
  Confidence: 0.99
  Late finding: first raised on code an earlier review cycle already covered.

Overall correctness: patch is incorrect
Overall confidence: 0.96

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning medium; reviewed against d34fbb47afe7.

Provenance checked

• CLI credential persistence and enablement keeps the original intent (23a89fb: The API-key setter supports consumed config credentials, stdin input, and enabling a provider when saving a key.)
• Unavailable plugin configuration preservation keeps the original intent (fd2eb38: Preserve unavailable provider/plugin records during config writes; the PR extends that existing test matrix to both new commands.)

Testing

Proof path: shipped entry point.

Security

None.

Evidence

What I checked:

• Pinned introduced change: Reviewed the merge-base-to-head change; current main has set-api-key and set-source but lacks the two proposed commands. Captured context sourceRevision: 8a370b26edb818d8a63178c941a5c270de2d008667fdff6e5e2adaf9b295485d. (Sources/CodexBarCLI/CLIConfigCommand.swift:28, d0828525d547)
• Insufficient capability detection: The new gate accepts an advertised web source or an environment-projected cookie; it misses settings-backed cookie consumers. (Sources/CodexBarCLI/CLIConfigCookieCommand.swift:59, d0828525d547)
• Augment consumes manual config cookies: Augment registers cookie-backed settings and no environment projections, advertises only auto/cli, and includes a web fallback that passes the configured manual cookie to AugmentStatusProbe. (Sources/CodexBarCore/Providers/Augment/AugmentProviderDescriptor.swift:54, d34fbb47afe7)
• Existing settings ownership: The CLI builds provider settings through the descriptor's credentialContribution; typed cookie registrations already translate config cookies into provider settings. (Sources/CodexBarCLI/TokenAccountCLI.swift:145, d34fbb47afe7)
• Contributor supplied runtime and upgrade proof: The redacted Linux transcript in feat(cli): add config set-cookie and config clear-credential #4765 (comment) shows fresh-config set, rejection, clear, no-op clear, mode 0600, and a whole-file comparison against a v0.81.0-created config that remains readable by v0.81.0. (d0828525d547)
• Existing CLI credential contract: Owner-authored Add config API key CLI #978 established consumed-credential validation and the API-key setter; Add CLI config set-source command #4197 established descriptor-driven source validation and preservation of unrelated config data. Neither approves these new commands. (Sources/CodexBarCLI/CLIConfigCommand.swift:273, 23a89fb02a08)

Labels

Label changes:

• add proof: sufficient: Contributor real behavior proof is sufficient.
• add rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦞 diamond lobster and patch quality is 🦐 gold shrimp.
• add status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action.
• remove rating: 🧂 unranked krab: Current PR rating is rating: 🦐 gold shrimp, so this older rating label is no longer current.
• remove status: 📣 needs proof: Current PR status label is status: ⏳ waiting on author.

Label justifications:

• P2: Useful scripting support with a limited provider-capability defect; existing configuration workflows remain available.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦞 diamond lobster and patch quality is 🦐 gold shrimp.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action.
• proof: sufficient: Contributor real behavior proof is sufficient.

Rating scale

6/6 🦀 challenger crab · 5/6 🦞 diamond lobster · 4/6 🐚 platinum hermit · 3/6 🦐 gold shrimp · 2/6 🦪 silver shellfish · 1/6 🧂 unranked krab. Overall follows the weaker of proof and patch quality; ✨ marks media proof (a screenshot, video, or linked artifact) that directly shows the changed behavior.

Workflow

ClawSweeper edits this one comment on every review. Comment @clawsweeper re-review for a fresh review only. Repair and merge execution lanes are retired.

History

Review history (1 earlier review cycle)

• reviewed 2026-10-25T04:15:11.529Z sha d082852 :: needs real behavior proof before merge. :: none

Reviewed October 25, 2026, 1:56 AM ET / 05:56 UTC (Revision 2).

[johan456789]

Proof for the review items above: a fresh config, an existing v0.81.0 config where only the requested fields change, and v0.81.0 reading the result (no new config fields).

Real binaries on Linux against a scratch CODEXBAR_CONFIG; credentials are placeholders. codexbar is this branch and codexbar-0.81.0 is the released CLI.

Fresh config: set, reject, clear, and no-op clear.

$ printf 'sessionKey=PLACEHOLDER' | codexbar config set-cookie --provider claude --stdin
Config: stored manual cookie for Claude and enabled
$ jq -c '.providers[] | select(.id == "claude")' config.json
{"cookieHeader":"sessionKey=PLACEHOLDER","cookieSource":"manual","enabled":true,"id":"claude"}
$ stat -c %a config.json
600
$ codexbar config set-cookie --provider elevenlabs --cookie a=PLACEHOLDER
elevenlabs does not support config cookies.
[exit 1]
$ codexbar config clear-credential --provider claude
Config: cleared manual cookie for Claude
$ jq -c '.providers[] | select(.id == "claude")' config.json
{"enabled":true,"id":"claude"}
$ codexbar config clear-credential --provider claude
Config: no stored API key or manual cookie for Claude

Existing v0.81.0 config: the diff of the whole file shows only the requested changes, and v0.81.0 still reads the result. No new config fields are introduced.

$ codexbar-0.81.0 config set-source --provider claude --source cli
$ codexbar-0.81.0 config enable --provider grok
$ printf 'sk-or-PLACEHOLDER' | codexbar-0.81.0 config set-api-key --provider openrouter --stdin
$ cp config.json before.json
$ printf 'sessionKey=PLACEHOLDER' | codexbar config set-cookie --provider claude --stdin --no-enable
$ codexbar config clear-credential --provider openrouter --api-key
$ diff <(jq -S . before.json) <(jq -S . config.json)
15a16,17
>       "cookieHeader": "sessionKey=PLACEHOLDER",
>       "cookieSource": "manual",
134d135
<       "apiKey": "sk-or-PLACEHOLDER",
$ codexbar-0.81.0 config validate
Config: OK

On the decision item: enabling on set matches set-api-key (--no-enable opts out). Clearing a cookie resets a manual cookieSource because a manual source with no header has nothing to send.

@clawsweeper re-review

[clawsweeper]

🦞👀
Exact review queued.

Re-review progress:

• State: Complete
• Detail: The durable review result and its route handoff completed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/40167406225
• Updated: 2026-10-25T05:58:15.118Z