Skip to content

Add pinned Codex deny-floor adapter - #1457

Closed
Chris0Jeky wants to merge 4 commits into
mainfrom
issue-1456/codex-deny-floor-adapter
Closed

Add pinned Codex deny-floor adapter#1457
Chris0Jeky wants to merge 4 commits into
mainfrom
issue-1456/codex-deny-floor-adapter

Conversation

@Chris0Jeky

@Chris0Jeky Chris0Jeky commented Jul 24, 2026

Copy link
Copy Markdown
Owner

T4 gate

Draft — exact-head CI and reviews are green, but do not merge until a maintainer has reviewed and trusted the project hook in a fresh interactive Codex /hooks session and recorded the real-engine allow/deny canaries. This PR stages a security boundary; it does not self-ratify or self-merge it.

Summary

  • add Taskdeck's repo-local Codex PreToolUse adapter for Bash
  • pin the reviewed canonical deny-floor v1.5.2 dispatcher declaration (9f38e906d49dd84de196bf22fc6388a5551494cf9b303610014ee6539783ebbb)
  • document the exact fresh-session /hooks trust procedure
  • state the boundary precisely: this is a Bash-command floor, not whole-tool containment, and the declared hash is audit-time metadata rather than a runtime byte check

No product behavior, API, database, frontend, docs/STATUS.md, or docs/IMPLEMENTATION_MASTERPLAN.md changes are included.

Verification

For the reviewed harness commands below, $TaskdeckRoot means the absolute #1457 PR-worktree path.

  • node scripts/check-docs-governance.mjs
  • node scripts/check-golden-principles.mjs
  • git diff --check origin/main...HEAD
  • structural JSON assertion: exactly one PreToolUse entry, ^Bash$, one command, timeout 5, no async/background, both platform commands contain the canonical pin and --event pre --runtime codex
  • py -3 -B scripts\agent_hooks\smoke_test.py with the real py -3 interpreter directory prepended to PATH: hook behavior smoke matrix passed
  • reviewed agent-harness 72639b8781e41c4872e700291d865afbf2110f19: installed canonical smoke_test.py reported 1604/1604 passed
  • reviewed harness.py doctor --repo $TaskdeckRoot: project Codex floor reported one project handler, one candidate, one current pinned handler; overall command remained nonzero only for the pre-existing missing user-skills check
  • reviewed harness.py audit --json $TaskdeckRoot: no adapter finding; overall command remained nonzero for pre-existing repository hygiene tracked by Docs truth & rotation: fix STATUS.md drift/bloat, repair broken links, add a link checker #1138/Adopt agent-harness T3 profile: harness right-sizing plan #1291
  • dotnet test backend/Taskdeck.sln -c Release — not run; no backend/product code changed
  • frontend typecheck/build/Vitest — not run; no frontend code changed
  • Playwright — not run; no UI or cross-surface behavior changed
  • fresh interactive Codex /hooks review plus real-engine allow/deny canaries — maintainer gate
  • exact-head PR CI: run 30063860671 passed all 15 jobs (including E2E Smoke) and CodeQL run 30063859670 passed all 4 jobs on a57b64aff4cf6f55057e163ba81c06dd5e4b31c8

Two independent adversarial reviews examined the implementation. Their findings and resolutions are recorded in a PR comment; both re-reviewed exact head a57b64aff4cf6f55057e163ba81c06dd5e4b31c8 after the documentation fix and reported no remaining findings. A fresh external Codex review then examined the same head and posted no inline thread or actionable finding.

Documentation

  • docs/STATUS.md updated — not applicable; shipped product reality did not change
  • docs/IMPLEMENTATION_MASTERPLAN.md updated — not applicable; roadmap did not change
  • docs/TESTING_GUIDE.md updated for the new verification flow
  • .codex/README.md and docs/agentic/AGENT_TOOL_PARITY.md updated with trust boundaries

Tracking

CI Workflow Validation

  • no .github/workflows/, deploy/, scripts/, or *.csproj files changed; CI Extended path trigger is not expected
  • intended ci-required.yml run 30063860671 and CodeQL run 30063859670 are green on exact head a57b64af

Risk Notes

@gemini-code-assist

Copy link
Copy Markdown

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

Copy link
Copy Markdown
Owner Author

Independent adversarial review record

Exact reviewed head: a57b64aff4cf6f55057e163ba81c06dd5e4b31c8

Two context-isolated reviewers used different lenses (correctness/documentation and security/trust-boundary). All findings, including lower severity, were resolved or tracked:

  • CRITICAL — non-Bash mutation surfaces are outside this adapter. The adapter only receives Bash events, so it is not whole-tool containment. Resolution: narrowed .codex/README.md and docs/agentic/AGENT_TOOL_PARITY.md to state that boundary and the compensating reliance on system/tool permissions. Durable cross-repo remediation remains tracked in agent-harness #2.
  • HIGH — the expected hash is declared but not compared with runtime dispatcher bytes. Resolution: docs now call it audit-time metadata checked by the reviewed doctor, explicitly not a runtime byte check; dispatcher changes require a pin refresh, reviewed doctor/audit, and fresh /hooks trust. Enforceable semantics are tracked in agent-harness #18.
  • MEDIUM — initial docs named nonexistent scripts\doctor.py and scripts\audit.py paths. Resolution: fixed in commit a57b64af to use the canonical agent-harness entrypoints and documented the reviewed harness commit.

Both original reviewers re-reviewed the fixed exact head. The correctness reviewer reported the prior finding fixed with no new findings. The security reviewer confirmed all three findings were either fixed in-scope or precisely tracked and reported no remaining finding for this narrow canonical Bash adapter.

Fix and verification evidence

  • Documentation fix: a57b64af Clarify Codex floor verification limits
  • Taskdeck docs governance: passed
  • golden-principles gate: passed
  • Taskdeck hook behavior smoke matrix: passed
  • reviewed canonical floor smoke matrix: 1604/1604 passed
  • structural adapter assertion: passed
  • git diff --check: passed
  • fresh interactive Codex /hooks trust and exact-head PR CI: still open gates; this draft must not be merged without them.

Copy link
Copy Markdown
Owner Author

@codex review

Please perform a fresh adversarial review of exact head a57b64aff4cf6f55057e163ba81c06dd5e4b31c8. Focus on whether the adapter exactly matches the reviewed canonical v1.5.2 shape, whether the documentation avoids overstating Bash-only coverage or audit-only hash semantics, and whether the T4 human trust gate remains explicit.

Copy link
Copy Markdown
Owner Author

Comment triage: the Gemini Code Assist sunset notice is informational and contains no review finding or requested change. No commit is associated with that notice.

@chatgpt-codex-connector

Copy link
Copy Markdown

Codex Review: Didn't find any major issues. Can't wait for the next one!

Reviewed commit: a57b64aff4

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Copy link
Copy Markdown
Owner Author

Review triage: Codex reviewed exact head a57b64aff4 and posted no inline thread or actionable finding. This is a clean review result, so no fix commit is associated with it.

Copy link
Copy Markdown
Owner Author

Exact-head verification update

Head remains a57b64aff4cf6f55057e163ba81c06dd5e4b31c8.

  • CI run 30063860671: success, 15/15 jobs successful, including both API-integration platforms and downstream E2E Smoke.
  • CodeQL run 30063859670: success, 4/4 jobs successful.
  • Fresh external Codex review examined a57b64aff4: no inline threads or actionable findings.
  • Full comment/review-thread sweep: zero inline comments, zero submitted review threads; Gemini sunset and clean Codex notices are explicitly triaged.

No PR head change occurred after the local reviews or CI. The sole remaining merge gate is human T4 activation evidence: fresh interactive Codex /hooks inspection/trust plus one allowed command and one denied non-writing force-push dry-run canary. This draft must not be merged before that evidence is recorded.

@Chris0Jeky

Copy link
Copy Markdown
Owner Author

Metadata review finding

Expected resolution: replace those placeholders with explicit PowerShell variables ($HarnessRoot and $TaskdeckRoot) or plain non-HTML tokens, then re-read both rendered bodies. This is PR/issue metadata only and does not change the reviewed commit.

@Chris0Jeky

Copy link
Copy Markdown
Owner Author

Metadata finding resolution

Resolved the LOW rendered-command finding in PR/issue metadata:

This was metadata-only: PR head remains a57b64aff4cf6f55057e163ba81c06dd5e4b31c8, all 20 exact-head checks remain successful, and review threads remain 0. No commit was appropriate because no repository file changed.

@Chris0Jeky

Copy link
Copy Markdown
Owner Author

Project-metadata review finding

  • MEDIUM — the project Priority gate is not actually satisfied. Targeted project-item reads show both linked issue Restore Taskdeck Codex deny-floor adapter and prove live hook trust #1456 (PVTI_lAHOA47lx84BPH_rzgz6qPs) and this PR (PVTI_lAHOA47lx84BPH_rzgz64fg) have Priority I labels but Priority: null. The earlier bulk audit result (scanned: 1000, needsUpdate: 0) silently omitted these newer items because Sync-TaskdeckProjectPriority.ps1 caps retrieval at 1,000 and does not detect saturation.

Tracked substrate fix: #1458. Before this PR can merge, set the project Priority for #1456 and #1457 to Priority I and verify both with targeted reads. This is metadata-only and does not invalidate exact-head code review or CI, but it is an additional merge gate alongside the human /hooks trust and actual-engine canaries.

@Chris0Jeky

Copy link
Copy Markdown
Owner Author

Runtime trust gate result: FAILED

Fresh maintainer evidence from the guarded #1457 worktree:

  • powershell -File scripts/worktree_guard.ps1 passed.
  • Codex v0.145.0 /hooks showed PreToolUse: 0 installed / 0 active.
  • The non-writing force-push canary reached Git and printed its dry-run result instead of being denied before execution.
  • A targeted git ls-remote origin refs/heads/codex-hook-canary returned no ref, confirming the dry-run did not create a branch.

Classification: project-hook discovery/trust failed. Green parser/smoke/CI evidence does not substitute for runtime activation. Do not mark ready or merge. No tracked Taskdeck mutation is permitted until a fresh session discovers the adapter, the maintainer reviews/trusts it through /hooks, and both actual-engine canaries pass.

Current diagnosis: .codex/hooks.json exists and the worktree is clean at a57b64af, but the global project-trust registry names the primary Taskdeck checkout, not this linked-worktree root. Do not hand-edit hook trust or use --dangerously-bypass-hook-trust. Retry by exiting the --yolo session and starting plain codex from the guarded worktree so Codex can present its normal project-trust flow.

Project Priority finding resolution

The previously empty project Priority fields were repaired with targeted project-item updates and directly re-read:

This resolves the PR-specific metadata finding without changing the PR head. Issue #1458 remains open for the audit script’s 1,000-item completeness defect.

@Chris0Jeky
Chris0Jeky marked this pull request as ready for review July 25, 2026 00:40
Copilot AI review requested due to automatic review settings July 25, 2026 00:40

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

@Chris0Jeky

Copy link
Copy Markdown
Owner Author

Fresh consolidation review ? blocked on authoritative hook source and floor drift

Exact Taskdeck head reviewed: a57b64aff4cf6f55057e163ba81c06dd5e4b31c8.

  • CRITICAL ? the adapter pin and prior evidence no longer match the installed/canonical dispatcher. This PR pins reviewed v1.5.2 SHA-256 9f38e906...83ebbb; the installed global dispatcher and current agent-harness/origin/main are now byte-identical v1.6.0 at normalized SHA-256 e76c358a...7cb299. The old 20/20 Taskdeck checks and reviews therefore do not establish the currently installed floor. Blindly repinning is not acceptable: upstream agent-harness #37 records command-laundering bypasses across 1.5.3/1.6.0/1.6.1, and #39 records a severe rollout false-positive regression.
  • HIGH ? the recorded linked-worktree activation flow targets a hook source Codex 0.145 intentionally ignores. The landed diagnosis in agent-harness PR #20 / #19 proves linked worktrees load .codex/hooks.json from the root checkout owning the common Git directory. Taskdeck root main has no adapter, while this worktree-only copy is ignored; 0 installed / 0 active is therefore explained, and the canary must not be repeated from this topology.

Disposition: return this PR to draft. Do not merge or rerun the force-push canary. First settle and merge the chosen agent-harness floor, sync that exact reviewed version globally, refresh this adapter pin and the source-location/trust documentation, then rerun authoritative doctor/audit, exact-head reviews and CI. Live proof must finally show at least one installed/trusted active hook before the allow command and denied non-writing canary.

This comment tracks the Taskdeck-side blocker under linked issue #1456; the cross-repo defects are already tracked by the upstream issues above. No Taskdeck commit is made in this containment step.

@Chris0Jeky
Chris0Jeky marked this pull request as draft July 25, 2026 00:49
@Chris0Jeky

Copy link
Copy Markdown
Owner Author

Containment evidence

PR #1457 is now back in draft. Head remains unchanged at a57b64aff4cf6f55057e163ba81c06dd5e4b31c8; no prior check/review result is being represented as current floor verification.

The two findings above remain open and are intentionally not ?fixed? by the draft transition. Resolution requires a reviewed final agent-harness floor, exact global sync, a refreshed adapter pin/source-location contract, new exact-head verification, and actual /hooks activation/canary evidence.

@Chris0Jeky Chris0Jeky moved this from Pending to Blocked in Taskdeck Execution Jul 25, 2026
@Chris0Jeky

Copy link
Copy Markdown
Owner Author

Not merging — and there is now a second, harder blocker than the human gate

Reviewed 2026-07-25 while clearing the PR queue. This one should stay a draft, and the reason has grown since it was opened.

1. The pinned hash no longer matches the installed dispatcher — verified

.codex/hooks.json pins 9f38e906d49dd84de196bf22fc6388a5551494cf9b303610014ee6539783ebbb, which this PR's body identifies as the reviewed canonical deny-floor v1.5.2.

The installed dispatcher is now FLOOR_VERSION = "1.6.5 (2026-07-25)". Computed with the harness's own function (harness.py:2478 normalized_text_sha256 — read UTF-8, \r\n\n, \r\n, sha256):

normalized_text_sha256(~/.claude/hooks/dispatch.py) = 91088f9b8cf6a56a6eb6ef49903defe902da152e4ed835e83e59db66298f9a33
pinned in .codex/hooks.json                         = 9f38e906d49dd84de196bf22fc6388a5551494cf9b303610014ee6539783ebbb
MATCH: False

Three minor floor versions have shipped since the pin was taken (1.5.2 → 1.6.5; I watched it move 1.6.4 → 1.6.5 mid-session today).

This PR's own rule already settles what that means. From .codex/README.md on this branch:

Any global dispatcher change requires an adapter pin refresh, reviewed doctor/audit, and fresh /hooks trust.

So merging as-is would ship an adapter whose audit-time declaration is stale on arrival, and harness.py doctor should flag it. The PR's verification block records a clean doctor run — that evidence was true when taken and is no longer.

2. The human gate is structural, not a formality

The PR states it plainly, and I agree with it:

Static checks (JSON parse, pin assertions) do not prove live activation; only an in-session allowed-command pass plus a denied dangerous command does.

That is a live-activation proof in an interactive Codex session. No agent can perform it, and no amount of review substitutes for it. It is tracked in OUTSTANDING_TASKS.md §E as of today so it stops living only in this PR body.

3. What is still good here

None of this is a criticism of the work. The adapter is a single pinned PreToolUse/Bash entry, the boundary is stated honestly (a Bash-command floor, not whole-tool containment; the hash is audit-time metadata, not a runtime byte check), and the structural assertions are the right ones. Two independent adversarial reviews and a Codex round found nothing outstanding. The design is sound; only its pin has aged.

Recommended path

  1. Refresh the pin to the 1.6.5 hash above — or, better, wait until the floor is stable, since it moved again today.
  2. Re-run harness.py doctor / audit and replace the verification evidence.
  3. Then the maintainer does the fresh /hooks trust session and records both canaries.
  4. Merge.

Related, from today's floor work: field evidence added to agent-harness #12, #21, #41, #45, and a new #56 (docker exec is not unwrapped at any tier). Taskdeck-side: #1475 (the repo hook denies 6 of 8 benign commands) and #1476 (scripts/agent_hooks/ has zero CI coverage) — #1476 in particular is worth landing before any further floor work.

The adapter pinned 9f38e906... (floor v1.5.2). The installed dispatcher is now
1.6.5, whose hash under the harness's own normalization (harness.py:2478
normalized_text_sha256 -- UTF-8, CRLF->LF, CR->LF, sha256) is 91088f9b...

Both the POSIX command and commandWindows carried the stale value; both updated.
Nothing else in the branch referenced it.

By this PR's own rule -- 'any global dispatcher change requires an adapter pin
refresh, reviewed doctor/audit, and fresh /hooks trust' -- the stale pin also
invalidated the recorded doctor/audit evidence and the trust step. This commit
addresses only the pin; the doctor/audit rerun and the interactive trust session
remain, and the trust session is maintainer-only by design.

Caveat worth stating: the floor moved 1.6.4 -> 1.6.5 during the session in which
this was written, so an audit-time hash pin against a fast-moving upstream will
go stale again. Re-verify at trust time rather than assuming this value holds.
@Chris0Jeky

Copy link
Copy Markdown
Owner Author

Pin refreshed — here is exactly what you need to do

You asked for the parts I can't do to come with precise instructions. The pin is fixed in 63df0780; everything below is the part that genuinely requires a human at an interactive Codex session.

What I changed

.codex/hooks.json pinned 9f38e906… (floor v1.5.2). Installed is 1.6.5, whose hash under the harness's own normalized_text_sha256 (harness.py:2478 — UTF-8, CRLF→LF, CR→LF, sha256) is:

91088f9b8cf6a56a6eb6ef49903defe902da152e4ed835e83e59db66298f9a33

Both the POSIX command and commandWindows carried the stale value; both updated. Nothing else in the branch referenced it. Structure re-validated: exactly one PreToolUse entry, matcher ^Bash$, one command, timeout 5, both platform strings carrying the pin and --event pre --runtime codex.


Your steps

Step 1 — Confirm the pin is still current (30 seconds)

The floor moved 1.6.4 → 1.6.5 during the session this was written in, so verify rather than trust:

python -c "import hashlib,pathlib; t=pathlib.Path.home().joinpath('.claude/hooks/dispatch.py').read_text(encoding='utf-8').replace(chr(13)+chr(10),chr(10)).replace(chr(13),chr(10)); print(hashlib.sha256(t.encode()).hexdigest())"

Expected: 91088f9b8cf6a56a6eb6ef49903defe902da152e4ed835e83e59db66298f9a33

If it differs, the floor moved again — tell me and I'll re-pin before you continue.

Step 2 — Rerun doctor and audit

The stale pin invalidated the recorded evidence, so this has to be redone:

cd C:\Users\jekyt\source\agent-harness
python harness.py doctor --repo C:\Users\jekyt\source\Taskdeck\.worktrees\codex-1456-codex-deny-floor-adapter
python harness.py audit --json C:\Users\jekyt\source\Taskdeck\.worktrees\codex-1456-codex-deny-floor-adapter

Looking for: the project Codex floor reports one project handler, one candidate, one current pinned handler, and no adapter finding. Both commands are expected to still exit non-zero for pre-existing unrelated reasons (a missing user-skills check; repo hygiene tracked by #1138/#1291) — that is fine, it is the adapter section that must be clean.

Paste the adapter section here and I'll read it.

Step 3 — The trust session ⚠️ this is the part only you can do

Open a completely fresh Codex session on the branch. Freshness matters: "project trust is not hook trust, and previously granted trust does not carry over to changed definitions" — and the definition just changed in step 1.

cd C:\Users\jekyt\source\Taskdeck\.worktrees\codex-1456-codex-deny-floor-adapter
  1. Run /hooks.
  2. Approve the single PreToolUse / Bash adapter. Confirm there is exactly one hook group — if you see two, stop and tell me.

Step 4 — The two canaries ⚠️ also only you

Static checks do not prove live activation. Only these do.

Allow canary — run any ordinary command:

git status --short

✅ Expected: runs normally.

Deny canary — a non-writing dangerous command:

git push --force --dry-run origin main

✅ Expected: denied, with a message prefixed [floor 1.6.5 (2026-07-25)].

--dry-run means nothing is pushed even if the floor were inactive — that is why this is the safe canary. If it is NOT denied, the hook is not active: stop and tell me. That is the exact failure this whole gate exists to catch.

Step 5 — Record and merge

Paste both canary results into this PR (the deny message verbatim, including the [floor …] prefix — it proves which floor answered). Then:

gh pr ready 1457
gh pr merge 1457 --merge

--merge, not rebase — the estate rule is a merge commit, and squash is disabled repo-side.


If you would rather not do this now

Nothing is broken by leaving it. It stages a security boundary that is not currently active, so the cost of waiting is only that the Codex runtime keeps running without the Bash floor the Claude runtime already has. Given the floor is shipping multiple versions a day right now, waiting for it to settle is a defensible call — the pin will just need refreshing again whenever you pick it up.

Related from today: the Taskdeck-side hook has its own live defect — #1475, it denies 6 of 8 benign commands — and #1476, scripts/agent_hooks/ has zero CI coverage. #1476 is worth landing before any further floor work regardless of what happens here.

@Chris0Jeky

Chris0Jeky commented Jul 25, 2026

Copy link
Copy Markdown
Owner Author

Fresh exact-head adversarial audit - do not merge or run canaries yet

Audited draft head 63df07804bd9424976f1d6b9ff45de30dd770764 against live main 438466f153b460e6d3bed34a1fdb79fcdc300a26 on 2026-07-25/26. This supersedes the earlier "canaries only" handoff.

CRITICAL / HIGH

  1. The linked-worktree /hooks procedure still targets a source Codex 0.145 ignores. main:.codex/hooks.json is absent; only this PR head contains it. Current Codex resolves linked-worktree hooks from the owning checkout/common-dir root, so starting the session in this PR worktree cannot prove this adapter active. The previous live attempt showed zero hooks and allowed the dry-run to reach Git. The topology finding remains unresolved.
  2. The floor version is not settled. This head and the locally deployed floor match v1.6.5 / normalized SHA prefix 91088f9b, but current agent-harness main is 91dc75d7 with dispatcher v1.6.11 / SHA prefix 78892044 after eight further dispatcher commits. Reconcile or explicitly bound producer/deployment drift before calling any pin canonical.
  3. Exact-head CI is red. There are 21 real checks: 20 success, 1 failure. DCO reports all four PR commits lack Signed-off-by. The enclosing workflow's advisory-success conclusion does not turn that red check green.
  4. Current-base evidence is stale. The branch is 72 commits behind live main; the merge result has not been tested.
  5. Current-head review evidence is absent. The two recorded adversarial passes and the only @codex review response target old head a57b64a; there are no substantive submitted reviews, requested reviewers, inline threads, or approvals for 63df0780.

MEDIUM / evidence drift

  • The PR body still describes v1.5.2 and old-head CI/review evidence.
  • Linked issue Restore Taskdeck Codex deny-floor adapter and prove live hook trust #1456 likewise retains obsolete pin/head acceptance evidence.
  • Fresh doctor/audit output after the pin change and a complete finding-to-fix-to-verification map are absent.
  • The PR remains draft and T4 maintainer-merge-only. Zero inline threads does not clear findings posted as ordinary comments.

Required recovery order

  1. Settle the reviewed dispatcher/deployment baseline and the root-checkout hook-source topology.
  2. Rebuild the change on current main with signed-off commits without rewriting this shared branch; update both bodies.
  3. Run static doctor/audit and local checks on that exact head.
  4. Obtain two independent exact-head adversarial reviews plus a fresh @codex review; resolve every finding; wait for exact-head CI with zero red or pending executable checks.
  5. Only then ask the maintainer for a fresh exact-repo/root-source /hooks inspection, allow canary, and deny canary.

The human gate should not be attempted against the current head. Findings remain tracked by #1456/#1457; no duplicate issue was created.

@chatgpt-codex-connector

Copy link
Copy Markdown

Codex couldn't complete this request. Try again later.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 63df07804b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread .codex/hooks.json
"hooks": [
{
"type": "command",
"command": "expected=91088f9b8cf6a56a6eb6ef49903defe902da152e4ed835e83e59db66298f9a33; python3 \"$HOME/.claude/hooks/dispatch.py\" --event pre --runtime codex",

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Resolve the POSIX dispatcher outside overridden HOME

In a trusted Linux or macOS checkout, this command cannot resolve the intended global dispatcher: the applicable .codex/config.toml unconditionally replaces PATH with Windows paths and HOME with C:\Users\jekyt\source\Taskdeck\.runtime-codex\home at lines 34-35. Consequently the hook either cannot find python3 or targets a Windows-literal .../.claude/hooks/dispatch.py, leaving the deny floor inactive or blocking shell use depending on hook-error handling. Scope these environment overrides to Windows or resolve the POSIX interpreter and account home independently.

Useful? React with 👍 / 👎.

Comment thread docs/TESTING_GUIDE.md

Note on the pin: the `expected` hash named in the adapter is an audit-time declaration — harness doctor checks it against the installed dispatcher's normalized bytes. The hook performs no runtime byte verification of the dispatcher; runtime enforcement design is tracked at https://github.com/Chris0Jeky/agent-harness/issues/18. When the global dispatcher changes, refresh the adapter pin, re-run reviewed doctor/audit, and re-trust the hook via `/hooks`.

These static checks prove structure and pin declaration only — they are insufficient to prove the hook is live. Actual activation additionally requires, in a fresh Codex session: re-trusting the hook definitions via `/hooks`, then observing one allowed command pass and one dangerous command denied (use a non-writing force-push dry run such as `git push --dry-run --force`). Report activation as NOT verified unless that live check was performed in the current session.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Attribute the activation canary to this hook

When Codex system policy or another permission layer rejects force-pushes independently, merely observing git push --dry-run --force being denied does not prove that .codex/hooks.json loaded or ran; the same change explicitly identifies those layers as compensating controls. This procedure can therefore certify an inactive security hook. Require hook-specific evidence, such as confirming that the denial is reported by this PreToolUse handler.

Useful? React with 👍 / 👎.

Comment thread .codex/hooks.json
"hooks": [
{
"type": "command",
"command": "expected=91088f9b8cf6a56a6eb6ef49903defe902da152e4ed835e83e59db66298f9a33; python3 \"$HOME/.claude/hooks/dispatch.py\" --event pre --runtime codex",

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Re-run verification for the dispatcher actually pinned

The committed adapter declares 91088f9…, but the commit's recorded doctor/audit, reviews, and exact-head CI refer to a57b64a, whose .codex/hooks.json still declares 9f38e906…; the commit message likewise describes the reviewed dispatcher as v1.5.2 with that older hash. Because doctor is the check intended to compare this audit-time declaration with the installed dispatcher, those results do not validate the configuration being reviewed. Re-run and record doctor/audit for 91088f9… before treating this adapter as verified.

Useful? React with 👍 / 👎.

Comment thread docs/TESTING_GUIDE.md
$TaskdeckRoot = (Resolve-Path .).Path
py -3 "$HarnessRoot\harness.py" doctor --repo $TaskdeckRoot
py -3 "$HarnessRoot\harness.py" audit --json $TaskdeckRoot
py -3 "$env:USERPROFILE\.claude\hooks\smoke_test.py"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Run the smoke suite from the reviewed harness

Although this section requires the checks to come from the harness worktree detached at the reviewed commit, this command instead executes an independently installed file under the user's global .claude directory. That copy can be stale or newer than $HarnessRoot, so an unreviewed test matrix can pass while appearing to satisfy the reviewed-harness gate; doctor validates the dispatcher pin, not the provenance of this smoke-test program. Invoke the suite from $HarnessRoot or verify the installed suite against the reviewed version before running it.

Useful? React with 👍 / 👎.

Comment thread docs/TESTING_GUIDE.md
Comment on lines +98 to +100
py -3 "$HarnessRoot\harness.py" doctor --repo $TaskdeckRoot
py -3 "$HarnessRoot\harness.py" audit --json $TaskdeckRoot
py -3 "$env:USERPROFILE\.claude\hooks\smoke_test.py"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Preserve failures from each deny-floor check

When this block is pasted into PowerShell or automation, a nonzero exit from doctor or audit does not terminate the sequence, and a successful final smoke command overwrites $LASTEXITCODE with zero. The commit already records that both earlier commands can return nonzero, so this can report the security-verification block green without establishing that the adapter-specific results passed. Add explicit adapter assertions and $LASTEXITCODE handling after each external command rather than relying on the final process status.

AGENTS.md reference: AGENTS.md:L78-L78

Useful? React with 👍 / 👎.

Copy link
Copy Markdown
Owner Author

Merge-gate checkpoint — 2026-07-27

The maintainer has authorized agent merges for all PR types once their actual gates pass, so the former type-based hold is lifted. PR #1457 is still not technically merge-ready and must not be merged yet:

  • all four shared commits lack DCO sign-off, so additive fixes cannot repair the failing DCO check without rewriting shared history;
  • the adapter pins obsolete floor v1.6.5;
  • installed v1.6.12 is not an eligible replacement pin (its producer review still has current correctness findings and the producer H-2 re-trust/canary gate is open);
  • canonical producer main is v1.6.15, but it is not deployed and its current producer review also has unresolved findings;
  • five current Codex threads on this PR remain unresolved;
  • no fresh exact-source /hooks activation, allowed control, or handler-attributed deny canary has been proven.

Safe recovery remains a new signed replacement branch/PR from final Taskdeck main after the agent-harness producer/deployment gate converges. Do not rewrite #1457. Once a replacement exists, change this PR's closing reference to non-closing, map and resolve its threads against replacement evidence, close it as superseded without deleting the branch, and let the replacement carry the single Closes #1456 link.

@Chris0Jeky

Copy link
Copy Markdown
Owner Author

Superseded by #1538, the signed replacement cut from current origin/main and pinned to the current reviewed/deployed deny-floor producer. This PR is retained as historical evidence and must not be merged.

@Chris0Jeky Chris0Jeky closed this Jul 27, 2026
@github-project-automation github-project-automation Bot moved this from Blocked to Done in Taskdeck Execution Jul 27, 2026
@Chris0Jeky
Chris0Jeky deleted the issue-1456/codex-deny-floor-adapter branch July 27, 2026 15:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

Restore Taskdeck Codex deny-floor adapter and prove live hook trust

2 participants