Fix repeated Codex native approval prompts after allow-always by shakkernerd · Pull Request #78234 · openclaw/openclaw

shakkernerd · 2026-05-06T03:01:55Z

This PR fixes the approval noise that showed up when OpenClaw sessions run through the native Codex harness, especially in guardian mode.

The user-facing problem was simple: Codex would try to do a routine shell action and Telegram would light up with approval cards. That was especially confusing in guardian mode, because guardian is supposed to review most of those requests itself. A command that should have been checked by Codex and then allowed or denied was instead getting surfaced to the human too early.

There were two separate approval paths overlapping.

The first path was the native Codex hook relay. Codex emits a native PermissionRequest for things like shell execution, and OpenClaw can relay that into its plugin approval UI. That relay already had an Allow Always button, but internally OpenClaw treated it the same as Allow Once: it returned a plain allow decision to Codex and forgot the user's choice. So if a Telegram user allowed the native approval for browserforce tabs, then asked for the same command again in the same session, OpenClaw could still ask again.

This PR makes that button mean what it says. Native allow-always decisions are remembered for the same session and the same concrete request: same provider, agent, session identity, tool name, cwd, and tool input. A different command, different cwd, different input, or different session still asks again. The cache is intentionally in-memory and short-lived, so it only removes the repetitive prompt without creating broad background permission.

Before:

User asks from Telegram: run browserforce tabs
Telegram shows native approval from openclaw-native-hook-relay-codex
User taps Allow Always
The command runs
User asks the same thing again
Telegram can show the same native approval again

After:

User asks from Telegram: run browserforce tabs
Telegram shows native approval from openclaw-native-hook-relay-codex
User taps Allow Always
The command runs
User asks the same thing again in the same session
The native approval is reused, and that card does not come back

The second path was Codex app-server approval. In guardian mode, Codex should own the real escalation decision: a sandboxed command fails because it needs network or filesystem access, the agent asks to retry with more permission, guardian reviews the specific request, and Codex either runs it or rejects it. OpenClaw was accidentally cutting in front of that flow by relaying Codex's early native PermissionRequest hook to Telegram before the app-server reviewer had finished. That is why a safe-looking command could produce a human approval prompt even though guardian would have approved it automatically a moment later.

This PR changes the default hook wiring for Codex app-server approval modes. When Codex approvals are active, OpenClaw no longer relays native permission_request hooks by default. Codex gets the first chance to review and resolve the escalation. Operators who explicitly need the old compatibility behavior can still opt into nativeHookRelay.events: ["permission_request"].

Before, a guardian-mode dev-agent command like this could immediately create a Telegram plugin approval card:

discord-cli channel read --channel <discord-channel> --limit 20

After, the same shape follows the intended Codex path. The sandboxed read fails on network access, the agent retries with escalation, guardian reviews the request, marks it low risk, and the command completes. In the dev-agent smoke test for this PR, no new plugin.approval.request was logged for that Telegram run.

There is one small supporting cleanup in the plugin approval layer. Approval requests can now declare which decisions are actually valid, and the gateway enforces that list instead of relying only on which buttons a chat client happens to render. That keeps native approval requests, app-server approval requests, and /approve replies aligned.

One thing this PR deliberately does not do: it does not change the post-denial override path. In native Codex clients, a guardian denial can be surfaced back to the user as an explicit “approve this denied action” affordance; the client then sends Codex the exact denied action so the model can retry with that approval context. OpenClaw does not wire that post-denial affordance into Telegram in this PR. This change is about removing the premature pre-guardian prompt and making native Allow Always stick for the request it actually approved.

clawsweeper · 2026-05-06T03:04:54Z

Codex review: needs maintainer review before merge.

Summary
The branch caches same-session Codex native allow-always PermissionRequest approvals, stops default pre-guardian PermissionRequest relays in Codex app-server approval modes, scopes plugin approval decisions, and updates protocol models, docs, changelog, and tests.

Reproducibility: yes. from source inspection: current main collapses native allow-always into one-shot allow and installs the native permission_request hook by default in Codex app-server approval modes. I did not run the live Telegram/Codex path.

Real behavior proof
Not applicable: Not applicable because this is a MEMBER/maintainer PR; the PR body and follow-up comment include live narrative and local proof, but the external contributor proof gate does not apply.

Next step before merge
No automated repair is needed; this protected maintainer PR needs exact-head CI completion and normal maintainer merge review rather than a replacement fix branch.

Security
Cleared: No concrete security or supply-chain regression was found; the diff narrows premature permission relays and adds server-side allowed-decision enforcement without touching dependencies, workflows, or secrets.

Review details

Best possible solution:

Merge this direction after exact-head CI completes or a maintainer accepts the supplied proof, preserving the exact-match in-memory cache and server-side allowed-decision enforcement.

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

Yes from source inspection: current main collapses native allow-always into one-shot allow and installs the native permission_request hook by default in Codex app-server approval modes. I did not run the live Telegram/Codex path.

Is this the best way to solve the issue?

Yes. The patch fixes the implicated relay, Codex app-server wiring, and approval validation surfaces with narrow exact-match scoping and an explicit compatibility opt-in.

Acceptance criteria:

pnpm protocol:check
pnpm test src/gateway/server-methods/plugin-approval.test.ts src/infra/plugin-approval-forwarder.test.ts src/plugin-sdk/approval-renderers.test.ts src/agents/harness/native-hook-relay.test.ts extensions/codex/src/app-server/run-attempt.test.ts -- --reporter=dot
git diff --check HEAD~1..HEAD
Wait for exact-head CI on a4d6378 to complete or for maintainer override.

What I checked:

Protected PR state: Live PR metadata shows authorAssociation MEMBER and the labels include maintainer, so this PR must stay open for explicit maintainer handling. (a4d6378a41b6)
Current-main allow-always root cause: Current main maps both allow-once and allow-always plugin approval results to the same one-shot native allow return, so the native relay does not remember allow-always. (src/agents/harness/native-hook-relay.ts:1341, 9c7c0ae891e8)
Current-main pre-guardian relay default: Current main registers the Codex native hook relay with the full default event set, including permission_request, regardless of Codex app-server approval policy. (extensions/codex/src/app-server/run-attempt.ts:1469, 9c7c0ae891e8)
PR allow-always implementation: PR head checks an exact-match allow-always cache before prompting and records allow-always decisions with provider, relay, agent/session identity, cwd, tool name, and canonical tool input in the key. (src/agents/harness/native-hook-relay.ts:931, a4d6378a41b6)
PR app-server approval ownership: PR head omits permission_request from default native hook relay events when Codex app-server approvals are active, while preserving explicit nativeHookRelay.events opt-in. (extensions/codex/src/app-server/run-attempt.ts:1486, a4d6378a41b6)
Server-side decision validation: PR head stores normalized allowedDecisions on plugin approval requests and rejects resolve decisions outside the request-scoped set before resolving the approval. (src/gateway/server-methods/plugin-approval.ts:187, a4d6378a41b6)

Likely related people:

pashpashpash: GitHub path history shows this person introduced the Codex native hook bridge and bounded native permission fingerprints; they also authored the later PR commits for guardian ownership and protocol refresh. (role: introduced behavior / adjacent owner; confidence: high; commits: 7a958d920c88, bf7d156bb099, fcfdf02b1679; files: src/agents/harness/native-hook-relay.ts, extensions/codex/src/app-server/run-attempt.ts, apps/macos/Sources/OpenClawProtocol/GatewayModels.swift)
steipete: Recent path history shows repeated maintenance and refactors in the Codex app-server and native hook relay surfaces touched by this PR. (role: recent maintainer; confidence: high; commits: 538605ff44d2, 0989f093246e, 5d7878dff165; files: src/agents/harness/native-hook-relay.ts, extensions/codex/src/app-server/run-attempt.ts)
joshavant: The plugin approval handler, protocol schema, forwarder, SDK, and Telegram approval surfaces trace back to the async requireApproval/plugin approval feature commit. (role: approval infrastructure introducer; confidence: medium; commits: 6ade9c474cf1; files: src/gateway/server-methods/plugin-approval.ts, src/infra/plugin-approvals.ts, src/infra/plugin-approval-forwarder.test.ts)

Remaining risk / open question:

Exact-head CI still had queued broad check/build shards at review time.
I did not live-run the Telegram/Codex guardian path in this read-only review; the source path is clear and the PR discussion includes live smoke-test narrative plus local command proof.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 9c7c0ae891e8.

pashpashpash · 2026-05-06T20:05:38Z

Refreshed the generated Gateway protocol models for allowedDecisions in a4d6378.

Local proof on the new head:

pnpm protocol:check
pnpm test src/gateway/server-methods/plugin-approval.test.ts src/infra/plugin-approval-forwarder.test.ts src/plugin-sdk/approval-renderers.test.ts src/agents/harness/native-hook-relay.test.ts extensions/codex/src/app-server/run-attempt.test.ts -- --reporter=dot
git diff --check HEAD~1..HEAD

The new exact-head CI run is queued now.

…aw#78234) * fix: reuse codex native approvals * fix: scope native approval reuse by session * fix: let codex guardian own native permission approvals * fix: refresh plugin approval protocol models --------- Co-authored-by: pashpashpash <nik@vault77.ai>

openclaw-barnacle Bot added docs Improvements or additions to documentation app: web-ui App: web-ui gateway Gateway runtime agents Agent runtime and tooling size: M maintainer Maintainer-authored PR labels May 6, 2026

This comment was marked as low quality.

Sign in to view

shakkernerd and others added 3 commits May 6, 2026 12:19

fix: reuse codex native approvals

f1bf2a8

fix: scope native approval reuse by session

a758b5e

fix: let codex guardian own native permission approvals

fcfdf02

pashpashpash force-pushed the fix/native-approval-reuse branch from 884e54c to fcfdf02 Compare May 6, 2026 19:29

openclaw-barnacle Bot added extensions: codex size: L and removed size: M labels May 6, 2026

fix: refresh plugin approval protocol models

a4d6378

openclaw-barnacle Bot added the app: macos App: macos label May 6, 2026

pashpashpash merged commit f011d6b into main May 6, 2026
104 of 106 checks passed

pashpashpash deleted the fix/native-approval-reuse branch May 6, 2026 20:55

github-actions Bot mentioned this pull request May 6, 2026

📡 Upstream Digest — 2026-05-06 21:03 UTC curtismercier/openclaw-mods#786

Open

clawsweeper Bot mentioned this pull request May 13, 2026

fix(codex): share native hook relay registry #73950

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Fix repeated Codex native approval prompts after allow-always#78234

Fix repeated Codex native approval prompts after allow-always#78234
pashpashpash merged 4 commits into
mainfrom
fix/native-approval-reuse

shakkernerd commented May 6, 2026 •

edited by pashpashpash

Loading

Uh oh!

clawsweeper Bot commented May 6, 2026 •

edited

Loading

Uh oh!

This comment was marked as low quality.

pashpashpash commented May 6, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

shakkernerd commented May 6, 2026 • edited by pashpashpash Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

clawsweeper Bot commented May 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment was marked as low quality.

pashpashpash commented May 6, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

shakkernerd commented May 6, 2026 •

edited by pashpashpash

Loading

clawsweeper Bot commented May 6, 2026 •

edited

Loading