Fix Android execpolicy lock fallback#4
Draft
GFernie wants to merge 3 commits into
Draft
Conversation
Allow persistent approval amendments to proceed on Android when file locking is reported as unsupported, while keeping unsupported lock errors as failures on non-Android targets. This matches Termux behaviour without widening the fallback elsewhere. Record the fork delta in the patch inventory and generate a dedicated patch artifact so the compatibility change is tracked in the same way as the other Termux-specific runtime patches. Verified with cargo test -p codex-execpolicy and bash verify-patches.sh. A full cargo build -p codex-cli could not be completed on-device because clang failed during the final link step with a bus error. Co-authored-by: Codex <codex@openai.com>
Keep the execpolicy fix tracked through source changes and the Termux patch inventory rather than treating it like a Bazel or toolchain patch file. This matches the existing meaning of the files under patches/, which are carried upstream and dependency patch assets rather than a general store of generated fork diffs. Verified with bash verify-patches.sh. Co-authored-by: Codex <codex@openai.com>
Add a Termux-backed regression test for execpolicy rule persistence. This exercises the real append path on Android instead of relying only on mocked Unsupported lock results. The fix is now verified three ways: cargo test -p codex-execpolicy, verify-patches.sh, and an interactive rebuilt codex session where persistent approval wrote a prefix_rule to default.rules without the previous lock() failure. Co-authored-by: Codex <codex@openai.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #3.
Summary
Allow persistent approval amendments on Android/Termux to proceed when advisory file locking is unsupported, while keeping the existing failure path on non-Android targets.
Problem
On Termux, choosing
pfor “always allow” approves the command but then fails to persist the rule because updatingdefault.ruleshits an unsupported file lock operation.Observed interactive failure:
The command still executes, but the allow rule is not persisted.
Change
The source fix is in
codex-rs/execpolicy/src/amend.rs.On Android only,
lock() not supportedis treated as a non-fatal advisory-lock miss when appending execpolicy amendments. Unsupported lock errors still fail on non-Android targets.The branch also carries the fork inventory updates in
patches/README.mdandverify-patches.sh, consistent with how this fork tracks its maintained deltas.Validation
cargo test -p codex-execpolicybash verify-patches.shcodexbinary on this device attarget/ci-test/codex--ask-for-approval on-requestrepro using the rebuilt binaryprefix_ruleentry to~/.codex/rules/default.rulesFailed to apply execpolicy amendment ... failed to lock policy file ... lock() not supportedwarning does not occur in the rebuilt flow