Codex binary preflight runs an uncached spctl --assess on every lookup (~2.5 s of syspolicyd CPU each; ~55% of a core when refresh cadence rises)

[dustball]

Summary

CodexLaunchPreflight.isLaunchCandidateAllowed spawns spctl --assess --type execute --verbose=4 on the native codex binary every time BinaryLocator.resolveCodexBinary runs, and nothing caches the verdict. On this Mac each assessment of the 281 MB x86_64 standalone codex costs ~2.5 s of syspolicyd CPU, and Gatekeeper does not cache a rejected (the code is valid but does not seem to be an app) verdict either, so the cost is linear in how often CodexBar looks codex up.

The CPU is billed to syspolicyd, not to CodexBar, so CodexBar's own CPU column looks idle while the fan runs. That made it hard to attribute.

Same class as #3837 (uncached signature validation on every refresh), on a different path.

Environment

• CodexBar 0.57.0 when observed. spctlAssessment(path:) and isLaunchCandidateAllowed(...) in Sources/CodexBarCore/PathEnvironment.swift are unchanged on v0.68.0 / main.
• macOS 15.7.7 (24G720), Intel Core i7-4790K, x86_64
• Codex CLI 0.145.0, standalone install: ~/.local/bin/codex → ~/.codex/packages/standalone/current/bin/codex (Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2), 281 MB, no quarantine xattr)
• Refresh frequency: 5 minutes (not Adaptive)

Measurements

Three back-to-back runs of spctl --assess --type execute --verbose=4 ~/.local/bin/codex, with syspolicyd otherwise idle:

run	wall	syspolicyd CPU	verdict
1	11.5 s	4.9 s	rejected (the code is valid but does not seem to be an app)
2	2.7 s	2.6 s	same
3	2.6 s	2.5 s	same

From the unified log (log show --predicate 'process == "spctl"'), every spctl parented by CodexBar:

• Normal: one pair per 5-minute refresh, 24 per hour, which is about 1.7% of a core in syspolicyd, continuously.
• Elevated: at one point the pairs started arriving every ~12 s (494 in one hour) and stayed there for 52 minutes. syspolicyd measured 16.5 s of CPU per 30 s (~55% of a core). Quitting CodexBar took it to 0.00 s per 30 s. The trigger for the faster cadence was not identified, but whatever raises the lookup rate, every lookup pays the full assessment.

Source-level cause

PathEnvironment.swift: resolveBinary → find / well-known paths → launchCandidateFilter (CodexLaunchPreflight.isLaunchCandidateAllowed) → spctlAssessment(path:), which launches /usr/sbin/spctl on every call. There is no memoization. Callers include CodexStatusProbe.fetch, resolveCodexExecutableForRPC, the Codex descriptor's binaryLocator, and CodexLoginRunner.

Expected

Cache the preflight verdict per resolved native binary, keyed on something that changes when the binary does (path + inode + size + mtime, or the code-directory hash), as #3857 did for the Chromium gate. An unchanged binary should not be re-assessed on every refresh.

Workaround

Set CODEX_CLI_PATH in CodexBar's environment, e.g. open --env CODEX_CLI_PATH=$HOME/.local/bin/codex -a CodexBar. resolveBinary returns an existing override before the preflight runs. Verified: 0 spctl children over a 6-minute window spanning a refresh, and Codex usage still fetched. Caveat: a Sparkle relaunch drops open --env variables, so the workaround has to be re-applied after each update.

[clawsweeper]

Codex review: this still needs some work. Reviewed September 27, 2026, 7:59 PM ET / 23:59 UTC.

Summary
Current main still assesses a discovered native Codex binary on each lookup, matching the reported repeated CPU cost. The earlier Chromium signature memo addresses a different preflight. A bounded fix is warranted, but caching a Gatekeeper verdict needs an approved freshness rule because this preflight also guards session scanning.

Reproducibility: yes. on macOS, repeated discovery of a native Codex binary reaches a fresh spctl process in current source, and the reporter supplies timing and process observations. This read-only Linux review did not run the macOS path.

Maintainer decision needed

Question	Recommendation
What maximum reuse interval is acceptable for Codex launch Gatekeeper results, including results used by session scanning?	Bounded memo: Approve a short expiry with file and bundle invalidation while retaining live malware and quarantine checks.

Why: Filesystem identity does not capture a later system trust revocation, and the same preflight guards a second launch-related path.

Next step
The source establishes a bounded performance defect, but a repair worker needs an approved Gatekeeper verdict expiry before changing this shared security preflight.

Security
Needs attention: The requested optimization would cache a security verdict used by launch-related paths.

Review details

Best possible solution:

Use a small, bounded assessment memo that rechecks malware and quarantine attributes on every lookup, invalidates on executable or bundle changes, and limits how long an unchanged Gatekeeper result can be reused.

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

Yes: on macOS, repeated discovery of a native Codex binary reaches a fresh spctl process in current source, and the reporter supplies timing and process observations. This read-only Linux review did not run the macOS path.

Is this the best way to solve the issue?

Unclear until the Gatekeeper freshness limit is approved. A narrow memo around assessment, with live attribute checks and replacement invalidation, addresses the repeated work without changing binary discovery.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• A cache based only on file identity could keep an allowed Gatekeeper result after trust is revoked without a binary change; the maximum reuse interval needs an explicit security decision.

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

Label changes

Label changes:

• add P2: Repeated assessment imposes measurable background CPU cost, while Codex usage remains available.
• add impact:other: The reported impact is sustained CPU and energy use in syspolicyd.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-security-review: Current issue advisory state selects this label.

Label justifications:

• P2: Repeated assessment imposes measurable background CPU cost, while Codex usage remains available.
• impact:other: The reported impact is sustained CPU and energy use in syspolicyd.

Evidence reviewed

Security concerns:

• [medium] Bound reuse of Gatekeeper decisions — Sources/CodexBarCore/PathEnvironment.swift:516
  File metadata can stay unchanged when system trust changes, so a successful cached assessment needs a defined expiry as well as file-change invalidation.
  Confidence: 0.9

What I checked:

• Repeated assessment path: The default Codex resolver passes each discovered candidate through the launch filter; the native-binary branch calls spctlAssessment, which starts /usr/sbin/spctl. No result memo is present in this path. (Sources/CodexBarCore/PathEnvironment.swift:516, 491ae688a89a)
• Refresh caller and override: The status probe resolves the Codex binary when it fetches; an executable CODEX_CLI_PATH override returns before candidate filtering. (Sources/CodexBarCore/Providers/Codex/CodexStatusProbe.swift:84, 491ae688a89a)
• Shared trust boundary: Local agent session scanning also calls the same launch preflight, so changing its assessment cache affects more than usage refresh. (Sources/CodexBarCore/LocalAgentSessionScanner.swift:76, 491ae688a89a)
• Existing behavioral tests: Preflight tests cover blocked malware attributes, rejected and revoked assessments, and the accepted non-app CLI verdict, but do not establish reuse of a verdict across lookups. (Tests/CodexBarTests/PathBuilderTests.swift:519, 491ae688a89a)
• Related but distinct work: The issue links Background Chromium cookie gate re-runs a full app-bundle code-signature validation on every refresh: ~11.6% of a core at idle, 190-217% CPU bursts every 60s #3837 and perf(keychain): memoize concurrent code-signature checks #3857. That work concerns Chromium cookie and Keychain signature validation; the Codex launch path still calls spctl directly. The PR context records a closed, unmerged branch, while local history contains a separate Keychain memo commit. (Sources/CodexBarCore/KeychainAccessPreflight.swift:410, 491ae688a89a)
• Release and history check: The v0.68.0 preflight still contains the assessment call, and comparison with the reviewed main revision showed no change to this file. File history identifies relevant May Codex launch work. Older patch blobs could not be inspected because the partial checkout's promisor fetch returned HTTP 403, so this evidence does not claim exact line introduction. (Sources/CodexBarCore/PathEnvironment.swift:516, 491ae688a89a)

Likely related people:

• Peter Steinberger: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• Larry Hao: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[dustball]

Fix is up in #4080 (it caches the verdict for the exact file Gatekeeper assessed, by inode, for 5 minutes, and ships the real-machine proof in .github/pr-proof/).

Until it lands, a workaround for anyone seeing syspolicyd busy with CodexBar running: launch CodexBar with CODEX_CLI_PATH set to your codex binary. BinaryLocator.resolveBinary returns an existing override before the Gatekeeper preflight runs, so no spctl happens at all:

open --env CODEX_CLI_PATH="$HOME/.local/bin/codex" -a CodexBar

(Adjust the path to wherever your codex lives. A Sparkle self-update relaunches without the variable, so re-apply it after updating.)