What is the Neural Link?

The Neural Link is a bi-directional bridge that connects AI agents directly to the Neo.mjs runtime. It lets agents inspect the Scene Graph, component state, event listeners, computed styles, and DOM rectangles, and mutate the running application in real time.

Why is Neo.mjs called an Application Engine instead of a framework?

Neo.mjs maintains persistent application objects in a worker-backed Scene Graph instead of compiling application state away into ephemeral DOM nodes. That architecture enables multi-window orchestration, runtime permutation, and deep AI introspection.

What is Context Engineering?

Context Engineering shapes the information and tool environment around AI agents. Neo.mjs implements it through Knowledge Base, Memory Core, GitHub Workflow, and Neural Link MCP servers for frontier harnesses, plus a File System MCP server for internal Neo.ai.Agent local loops.

What is the Neo.mjs Agent OS?

The Neo.mjs Agent OS is the repository Brain: source code and services for Memory Core, Knowledge Base, Active Hybrid GraphRAG, DreamService, Golden Path synthesis, A2A coordination, and Neural Link tooling.

Frontmatter

id	14421
title	Codex harness PR-lifecycle allow/deny parity
state	Closed
labels	enhancementdeveloper-experienceaibuildmodel-experience
assignees	neo-gpt
createdAt	Jul 2, 2026, 3:55 AM
updatedAt	Jul 2, 2026, 8:39 AM
githubUrl	https://github.com/neomjs/neo/issues/14421
author	neo-gpt
commentsCount	0
parentIssue	null
subIssues	[]
subIssuesCompleted	0
subIssuesTotal	0
contentTrust
projected
quarantined	0
signals	[]
blockedBy	[]
blocking	[]
closedAt	Jul 2, 2026, 8:39 AM

Codex harness PR-lifecycle allow/deny parity

Closed v13.1.0/archive-v13-1-0-chunk-8 enhancementdeveloper-experienceaibuildmodel-experience

neo-gpt commented on Jul 2, 2026, 3:55 AM

Context

PR #14417 landed Claude-side deterministic PR-lifecycle permissions in .claude/settings.template.json: the safe routine lifecycle subset is allowlisted, dangerous variants are denied, and raw git push remains classified until the parser-shaped wrapper work in #14419. The operator follow-up is parity: Codex maintainers are equal peers, so Codex should not stay behind Claude on routine lifecycle mechanics if the Codex harness has a supported policy surface.

The V-B-A anchor from current origin/dev is asymmetric:

.claude/settings.template.json now has permissions.allow, permissions.deny, and permissions.ask arrays for PR-lifecycle commands and guardrails.
.codex/config.template.toml currently carries MCP server setup, network access, context settings, and hook enablement, but no tracked command allow/deny policy surface.
.codex/hooks.json wires Codex context + Stop hooks; it is not a command approval policy.
codex --help exposes config overrides and sandbox/approval modes, but this pass did not surface a public repo-scoped command allow/deny schema. The implementation must prove the supported Codex shape before committing keys.

The Problem

Claude now has mechanical permission help for the daily agent PR lifecycle. Codex still relies on the live harness approval/sandbox behavior plus prose guidance for the same routine work. That creates unequal maintainer ergonomics and a predictable MX split: Claude can avoid model/classifier prompts for safe repeated commands, while Codex may still spend interaction cycles on commands that are already narrowed by repo policy.

The safety bar is the same one learned in #14417: parity is not permission sprawl. Static policy may only cover commands whose dangerous grammar is bounded. Raw push must not be allowlisted by prefix; #14419 owns the parser-shaped push boundary.

The Architectural Reality

Claude's tracked source is .claude/settings.template.json; active .claude/settings.json is gitignored and preserves local operator edits except when missing.
Codex's tracked source is .codex/config.template.toml; active .codex/config.toml is gitignored and may contain local trust or machine-specific settings.
Codex-specific runtime guidance lives in .codex/CODEX.md, injected through .codex/hooks.json because root AGENTS.md wins project-doc discovery.
The current Codex tracked template has no command-policy section. The implementation must first verify whether Codex supports repo/project-scoped command approval or denial rules. If it does not, do not commit unsupported config keys; document the verified boundary and file the required upstream/substrate follow-up.

The Fix

Verify the Codex-supported policy surface for command allow/deny or approval rules using a falsifying local harness check: config parse with --strict-config where applicable, fresh Codex Desktop/CLI startup, and one intentionally safe/unsafe command probe.
If Codex supports a tracked project-level policy, add the Codex equivalent of the #14417 safe lifecycle subset to the tracked template/source of truth:
- allow/approve: npm run agent-preflight*, git add *, git commit *, git checkout -b codex/*, git checkout dev, git pull origin dev, git fetch*, read-only git inspection commands, gh pr create/view/edit/checks/list, and gh issue view/list.
- deny/block: gh pr merge, git push* --force*, git push* -f *, colon-refspec push forms, git push origin dev*, git push origin main*, git commit* --no-verify*, and git commit* -n *.
Keep raw git push classified until #14419 or a generalized parser wrapper proves the destination boundary for Codex branch names.
Update .codex/CODEX.md only as needed to document adoption, local override, and any verified Codex schema limitations.
Add focused validation so unsupported Codex config keys cannot silently land.

Contract Ledger Matrix

Target Surface	Source of Authority	Proposed Behavior	Fallback / Edge Case	Docs	Evidence
Codex command-policy surface (existing if Codex supports it, otherwise new/unsupported boundary)	Operator parity request + #14417 + #13652	Encode the safe PR-lifecycle command allow/deny policy for Codex without widening beyond Codex branch conventions.	If Codex has no supported repo-scoped policy, do not fake parity with invalid keys; document the limitation and file the follow-up/upstream route.	`.codex/CODEX.md` if behavior or adoption differs from Claude.	`codex --strict-config` or equivalent active-harness proof plus safe/unsafe command probe.
`.codex/config.template.toml`	Existing tracked Codex MCP/config template	Carry only supported, repo-shareable Codex config; no secrets, no machine-local paths, no unsupported schema.	Active `.codex/config.toml` remains ignored for operator-local overrides.	Inline comments if a new section is added.	Config parse / startup validation; diff confirms `.codex/config.toml` untouched.
Codex PR-lifecycle command policy	#14417 safety boundary + AGENTS critical gates	Safe read/branch/commit/PR commands can run without repeated approval where Codex supports it; unsafe merge/direct-push/force/no-verify/refspec forms are blocked or remain approval-gated.	Raw push remains classified until #14419 or equivalent wrapper is available for Codex branch names.	`.codex/CODEX.md` if the harness cannot mechanically deny one of the dangerous forms.	Positive and negative probe matrix, including at least one approved safe command and one denied unsafe command.

Acceptance Criteria

Codex command-policy support is verified before implementation. The PR names the exact supported schema or states that repo-scoped command policy is unavailable.
If supported, the tracked Codex source of truth gains parity for the #14417 safe lifecycle subset using Codex branch naming (codex/*) and no raw git push allow.
Dangerous forms are denied/blocked where Codex supports hard denial: gh pr merge, direct dev/main push, force push, colon-refspec push, and git commit --no-verify / -n.
If any hard-deny equivalent is unavailable, the PR documents the exact residual risk and files or links the follow-up needed for real parity rather than claiming parity in prose.
.codex/config.toml remains ignored and unmodified; no secrets or machine-local paths are committed.
Focused validation proves config compatibility and policy behavior: strict config parse/startup plus safe/unsafe command probes, or a documented impossibility proof if Codex lacks the surface.
Post-merge validation: a fresh Codex harness can perform the allowlisted routine lifecycle subset without repeated approval prompts, while an unsafe command remains blocked or approval-gated.

Out of Scope

Implementing #14419's push parser or allowing raw git push by prefix.
Changing Claude settings beyond any shared documentation pointer needed for parity.
Broad gh api, arbitrary git *, arbitrary Bash(*), or destructive reset/checkout allowances.
Editing ignored local .codex/config.toml as the delivered artifact.

Avoided Traps

Inventing Codex config keys - parity must be proven against the actual Codex harness schema, not guessed from Claude's JSON shape.
Prefix-based push safety - #14417 already falsified that boundary; push safety requires grammar parsing, not static source-prefix matching.
Documentation-only parity - if Codex supports hard policy, implement it mechanically. If it does not, say so explicitly and route the missing substrate.

Decision Record impact

none. This is aligned with #13652's mechanical-enforcement direction and follows #14417's permission-layer precedent without changing an ADR.

Related: #13652, #14417, #14419

Live latest-open sweep: checked latest 20 open issues at 2026-07-02T01:53:45Z; no equivalent found. Closest adjacent open ticket is #14419, which owns push grammar, not Codex harness parity. A2A in-flight sweep: checked recent 30 non-archived messages at 2026-07-02T01:53:45Z; no competing [lane-claim] / [lane-intent] on Codex allow/deny parity found.

Origin Session ID: 8facbc96-c346-4633-9141-79a968ca1c5d Retrieval Hint: "Codex harness PR-lifecycle allow deny parity" · "Claude settings #14417 Codex config.template command policy"

tobiu referenced in commit 597ee98 - "feat(codex): add PR lifecycle execpolicy rules (#14421) (#14432)" on Jul 2, 2026, 8:39 AM

tobiu closed this issue on Jul 2, 2026, 8:39 AM