OpenAI Codex CLI

481 functions exceed the cyclomatic-complexity threshold of 10 — 441 of them in Rust, 39 in Python, 1 in JavaScript. The worst single function is handle_event in codex-rs/tui/src/app/event_dispatch.rs at complexity 122. The supporting checks tell the same story: 1,639 sites nest too deeply (1,546 in Rust), 881 functions run past the length threshold (875 Rust), and 23 functions take too many parameters. This is genuine, handwritten complexity in the core — not a generated-code artifact.

Why this is new. Our first study scored complexity as a pass, because at the time inkode only measured cyclomatic complexity for Python. The engine now does the full analysis in-process for Rust, TypeScript and JavaScript too. The Rust core was always this complex — we just couldn't see it before. The takeaway is that the agent loop (event_dispatch, parse_command, the session machinery) carries the kind of branching density that makes every change a careful one.

Seven hardcoded credentials. Two are in codex-rs/cli/src/login.rs (lines 462 and 468) — the login flow itself — flagged as generic API keys. The rest are spread across the codebase: a generic key in core-plugins/src/remote/catalog_cache.rs, one in a WebSocket connection-handling test, one in the generated Cargo.lock, and two private keys in agent-identity/src/lib.rs and login/src/auth/auth_tests.rs.

How to read this set. Test-fixture and lockfile secrets are normally low-risk — disposable keys nobody is actually using. The two in cli/src/login.rs and the one in catalog_cache.rs are the ones worth a closer look: a generic-API-key pattern in production code is usually either a sample constant that belongs in a test, or a hardcoded fallback that needs to go away. Triage by opening the file; the answer takes 30 seconds. (inkode redacts the matched value before anything leaves the machine, so the secret itself is never uploaded.)

The single biggest structural issue is still a generated TypeScript barrel. codex-rs/app-server-protocol/schema/typescript/v2/index.ts now re-exports 472 modules — combined degree 473 against a default threshold of 20, up from 461 last time. Two sibling union types (ClientRequest.ts at 82 and ServerNotification.ts at 67) repeat the pattern at smaller scale. On the inbound side, AbsolutePathBuf.ts is imported by 51 other modules. No circular dependencies across 2,814 packages.

Why this matters. A barrel that re-exports 472 modules pulls every consumer into the entire schema. Editor tooling slows down, tree-shaking stops working, and any change to the schema invalidates the build cache for every dependent. It's also a refactor blocker: nobody can split this file cleanly because every renumbered re-export is a breaking change. The good news is the cause is generation, not handwriting — the generator template can produce domain-scoped sub-barrels in an afternoon.

Headline: 1,360 test files for 1,452 source files — a 94% ratio. That's the headline. The per-directory breakdown is less flattering: 112 directories have source code but no tests next to them, including the generated TypeScript schema layer and most of the Python SDK. The Rust crates lean hard on Rust's convention of inline #[cfg(test)] modules, which the check counts at the file level — that's where the 94% comes from. Strip the inline tests out and the picture changes considerably.

How to read this. A high test-to-source ratio is a necessary condition for refactor-safety, not a sufficient one. The 112 untested directories include the entire generated-TypeScript surface (lower priority — tests belong on the generator, not the output) and the Python SDK (higher priority — this is the interface third parties consume). The Rust core is genuinely well-tested. The risk to watch is regression in the Python SDK, where there's no safety net.

609 of 3,969 scanned files exceed the 500-line warning threshold; 256 of those exceed 1,000 lines. The worst offenders are generated — the JSON schema dumps (codex_app_server_protocol.schemas.json at 19,513 lines), Cargo.lock, the v2_all.py SDK bundle. But not all of it is machine emitted: codex-rs/tui/src/bottom_pane/chat_composer.rs is a handwritten Rust file at 11,189 lines. A .ik.yaml exclusion on the schema and lock paths would collapse this finding by an order of magnitude and surface the handwritten outliers worth splitting.

Why we still flag generated files. Big files are an onboarding tax. Every new contributor has to scroll through them; every diff against them is harder to review. We don't auto-exclude generated code — the existence of a 19,000-line file in a repo is useful signal, even if the explanation is “the generator emits it.” The takeaway is operational: tell the scanner what's generated so the next scan can focus on what humans wrote.

Out of 3,867 changed files in the analysed window, a handful carry most of the churn — and they cluster in two directories. codex-rs/core/src/session/ (tests.rs, mod.rs, turn.rs, turn_context.rs) is one; codex-rs/core/src/config/ (mod.rs, config_tests.rs) is the other, alongside the app-server-protocol JSON schema bundle. Together they account for the bulk of the change risk. High-churn + high-complexity is the architectural pressure point worth watching — and the session machinery sits at the top of both lists.

How to use this. Hotspot × complexity is where bugs land. If you have one person-week to harden this codebase, spend it on codex-rs/core/src/session/ and config/: that's where the change is happening, that's where the product behaviour lives, and that's where a regression has the biggest blast radius. The schema churn is a different story — it's machine-driven and predictable; you don't review the diffs, you review the generator.

17 file pairs change together more often than chance. Most pair a Rust source file with its generated TypeScript schema sibling — the schema is regenerated whenever the Rust type changes, which is the design. The pattern to watch is the few cross-cutting pairs that aren't schema-driven: those are real hidden dependencies the codebase doesn't declare.

What's signal vs noise here. Schema ↔ type co-change is expected and tells you nothing new. The interesting pairs are the ones where two files in different domains keep moving in lockstep without an explicit import between them — that's the “temporal contract” that bites later when one of them is touched by someone who doesn't know the other exists. Worth filtering the full coupling list by “neither file imports the other” before triaging.

8 magic-number literals (7 in JS, 1 in Python) — far fewer than the 122 we reported last time, because the check now leans on pylint and eslint rather than a regex heuristic that over-counted. 41 shell-script issues across 17 scripts (ShellCheck-driven: unrecognised shebangs, brace-group parse errors, unquoted expansions). And 22 bare except: clauses in the Python SDK and the bundled skill samples. None of these alone moves the score; together they're the kind of paper-cut work a reviewer would flag on a first pass.

Why bare-except is the one to fix first. Magic numbers are an audit problem. Shell-script warnings are a CI-reliability problem. But bare except: is an in-production problem: it swallows KeyboardInterrupt, SystemExit, and every real bug along with the one error you meant to catch. In a long-running process, that's how this-should-have-thrown turns into silent data corruption. 22 of them in an SDK that other people will embed in their software is the finding here.