| Preflight | Tool already supports keyring and the user's workflow tolerates it | Prefer keyring over custom wrappers | Confirm the CLI authenticates without plaintext auth.json | Fall back to encrypted-file launcher | replace |
| Preflight | User wants codex -p NAME to select a custom provider/model on Codex CLI profile v2 | Put provider connection details only in ~/.codex/config.toml under [model_providers.NAME], then put model and model_provider in ~/.codex/NAME.config.toml | Run codex exec -p NAME --ephemeral --skip-git-repo-check 'Return exactly: ok' and confirm the startup banner shows the intended model: and provider: | If strict config fails, separate unrelated stale config-field cleanup from the provider/profile test | branch |
| Preflight | User wants Codex secure launch | Use scripts/codex_secure_launch.sh and a provider-specific env_key when needed | Launch codex ... through the wrapper and confirm auth works | Re-check provider name, env_key, and encrypted file path | branch |
| Preflight | User wants opencode run with an encrypted key and ~/.opencode/pass.txt | Prefer the dedicated opencode-secure-mcp capability for reusable task execution; otherwise use scripts/opencode_secure_run.sh as the compatibility wrapper | Run a secure opencode task and confirm a response arrives | Add the required env key with --env-key, pick the correct model/provider mapping, or rebuild the encrypted key | branch |
| Validation | Need to verify opencode wrapper auth without changing broader runtime state | Do not isolate with temporary XDG_DATA_HOME; first compare manual MIFY_API_KEY=... opencode run ... against wrapper launch under the normal user data directory | Confirm wrapper and manual env launch behave the same under the normal XDG layout | If behavior differs, debug env injection or encrypted key contents before attempting any auth-store surgery | replace |
| Validation | Wrapper run under the normal XDG layout reaches the provider but returns 401 Invalid API Key while a manual MIFY_API_KEY=... opencode run ... succeeds | Treat this as proof that the encrypted credential contents differ from the manual env value; rebuild ~/.opencode/auth.key.enc from the known-good env key | Confirm manual env succeeds and wrapper fails under the same normal XDG layout | Replace the encrypted file with one generated from the validated key | branch |
| Validation | Wrapper fails before opencode starts and openssl reports it cannot read the encrypted input cleanly | Treat this as an encrypted-file format mismatch first; rebuild ~/.opencode/auth.key.enc with the same cipher, PBKDF2, iteration count, and supported output mode the wrapper expects | Confirm the failure happens before any provider request is emitted | Replace the hand-made encrypted file with one generated by the approved workflow | branch |
| Guardrail | An implementation plan suggests reading ~/.opencode/pass.txt directly or calling openssl manually | Reject that path and route through scripts/opencode_secure_run.sh or the opencode-secure-mcp wrapper-backed server | Confirm the final command begins with the wrapper path rather than openssl | Stop and explain the boundary | block |
| Rotation | Raw API key changes but provider wiring stays the same | Rebuild only the encrypted file, keep wrappers and config stable | Re-run the normal wrapper command successfully | Restore encrypted-file backup and re-check passphrase and provider settings | continue |
