Repository navigation
Fix Droid API-key recovery instructions - #5065
vincent-peng wants to merge 1 commit into
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review completeClawSweeper finished reviewing this revision. The review result is being finalized. |
Codex Review Summary: ✅ CompletedThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Codex review: needs maintainer review before merge. What this changesThis PR adds the required stdin flag to Droid’s API-key recovery command and documents the resolved configuration location. Example: Pipe a nonempty Factory API key into the command quoted by the missing-key message.
Review scores
ProductKind: Bug fix · Worth it: Yes · Fix scope: Complete Merge readiness✅ Ready for maintainer review Keep open: this PR fixes demonstrably unusable recovery guidance with a small, focused change; no introduced correctness or security defects were found. Priority: P2 Before mergeNone. FindingsNone. Agent review detailsHow this fits togetherThe Factory provider emits a missing-key error during explicit API usage; its recovery guidance directs users to the existing CLI setter, which reads stdin and writes through the shared configuration store. flowchart TD
A[Factory API usage] --> B[Missing key message]
B --> C[CLI stdin setter]
C --> D[Resolved configuration file]
D --> E[Subsequent provider usage]
Technical reviewBest possible solution: Land the focused guidance correction using the existing stdin setter and shared config resolver. Do we have a high-confidence way to reproduce the issue? Yes: current-main guidance omits both accepted input options, and the setter source necessarily rejects that command even with piped input; the contributor also reports matching base/head executable results. Is this the best way to solve the issue? Yes: adding the existing --stdin flag and linking the authoritative config documentation fixes the misleading guidance without changing credential handling or duplicating configuration ownership. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against 7447bc77c249. Provenance checked
TestingProof path: shipped entry point. SecurityNone. EvidenceWhat I checked:
Likely related people:
Preflight sourceSource unknown. Source comparison at the observed PR snapshot only. Completion is self-reported; body, policy, tests, execution, and report bytes are not verified. LabelsLabel changes:
Label justifications:
Rating scale6/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. WorkflowClawSweeper edits this one comment on every review. Comment Reviewed November 11, 2026, 7:12 PM ET / November 12, 2026, 00:12 UTC. |
Summary
Droid's missing-API-key message recommends a setter command without its required input option and assumes the legacy config path. The message now explicitly says to pipe a key into the stdin setter, and the Factory docs describe the resolved configuration file.
A portable regression extracts the command from the displayed error and resolves the real registered CLI action. Authentication, source selection, fallback, and config-writing behavior are unchanged.
Behavior proof
Checked source-built macOS CLI executables at base
7447bc77c2497323d9c41e40164ce705533493c8and headbe435d60bb8f485d5c2d2fe3ea45624d4e07e6e6. Both setter invocations received the same nonempty synthetic input on stdin.codexbar config set-api-key --provider factoryMissing API key. Pass --api-key <key> or pipe it with --stdin.codexbar config set-api-key --provider factory --stdinControls cover existing default XDG config, custom
XDG_CONFIG_HOME,CODEXBAR_CONFIG, and legacy-only installs. A truly fresh usage read creates no config, and a subsequently created legacy file remains supported. Saving preserves the configured Web source and session accounts, enables by default, honors--no-enable, rejects blank input before writing, and produces private config-file permissions.All command checks use synthetic homes, files, and key values with network and Keychain access blocked. They exercise local configuration storage without provider requests.
Validation
./Scripts/test_fast.sh --filter 'FactoryAPIKeyGuidanceTests|FactorySettingsReaderTests|FactoryAPIFetchStrategyTests|FactoryAPIKeyProbeFetchTests|CLIConfigCommandTests|ConfigValidationTests' --jobs 4: 74 tests passed across six suites. The new regression failed on the base message at the missing stdin flag.make checkwith Python 3.14.node Scripts/check-documentation-links.mjs.