Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve.

Summary
Keep open: current main appears to contain the same fix, but the issue has a protected maintainer label and is paired with an open closing PR, so it needs explicit maintainer handling rather than automated cleanup.

Reproducibility: no. On current main, the source path now reads tools.exec.security, and regression tests cover both canonical values and the stale agents.defaults.exec.security case.

Next step
Not a repair-lane candidate because the protected label and linked open fix PR require maintainer handling, and current main already contains the narrow code/test fix.

Review details

Best possible solution:

Keep the current main extractor/test behavior, then have a maintainer explicitly close this issue as implemented on main or resolve the linked PR as redundant/superseded.

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

No. On current main, the source path now reads tools.exec.security, and regression tests cover both canonical values and the stale agents.defaults.exec.security case.

Is this the best way to solve the issue?

Yes. Reading the canonical config path inside extractQuickSettingsSecurity is the narrowest maintainable fix; the remaining question is maintainer workflow for the protected issue and linked open PR.

What I checked:

Protected label: The provided GitHub context shows the issue is labeled maintainer, which blocks automatic close/cleanup even when current main has strong implementation evidence.
Linked open fix PR: The issue body and timeline point to the open, unmerged fix PR fix(ui): read exec security from tools config #79207, so the issue/PR pair should be resolved together by a maintainer.
Current source reads canonical config: extractQuickSettingsSecurity now initializes the badge value from cfg.tools.exec.security and trims non-empty string values. (ui/src/ui/app-render.ts:581, 79e31421225b)
Regression coverage: The colocated test asserts tools.exec.security values render and that agents.defaults.exec.security is ignored as a stale non-schema path. (ui/src/ui/app-render.exec-policy.test.ts:11, 79e31421225b)
Config source of truth: Exec approvals docs describe effective policy as coming from tools.exec.*, including tools.exec.security for the host exec layer. Public docs: docs/tools/exec-approvals.md. (docs/tools/exec-approvals.md:18, 79e31421225b)
Fix provenance and release state: Commit 30214a40cb7c5fa5d6833f57fd4884bc17ffb787 is fix(ui): read exec policy from tools config; git tag --contains returned no tags, and the changelog entry is under Unreleased. (CHANGELOG.md:5, 30214a40cb7c)

Likely related people:

Val Alexander: Blame and commit history show Val authored the current extractor behavior, regression test, and nearby recent Control UI commits. (role: recent maintainer and fix/proof owner; confidence: high; commits: 30214a40cb7c, 5ae385b2f0f1, 79e31421225b; files: ui/src/ui/app-render.ts, ui/src/ui/app-render.exec-policy.test.ts, CHANGELOG.md)
BunsDev: The fix commit title credits @BunsDev, and the changelog shows repeated recent Control UI work credited to this contributor around the same surface. (role: adjacent Control UI contributor; confidence: medium; commits: 30214a40cb7c; files: ui/src/ui/app-render.ts, CHANGELOG.md)

Remaining risk / open question:

The fix is not proven shipped in v2026.5.7; git tag --contains returned no tags and the changelog entry remains under Unreleased, so released users may still see the old behavior until the next release.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 79e31421225b; fix evidence: commit 30214a40cb7c, main fix timestamp 2026-05-07T22:58:47-05:00.

Uh oh!

Uh oh!

Quick Settings reads stale exec security config #79247

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions