fix(codex): match reworded trust dialog on codex-cli 0.144.1 (#410)

[SparkyWen]

Match reworded Codex trust dialog (codex-cli 0.144.1)

Fixes #410.

Problem

codex-cli 0.144.1 reworded its workspace-trust dialog from
"… allow Codex to work in this folder …" to
"Do you trust the contents of this directory? … › 1. Yes, continue".

TRUST_PROMPT_PATTERN only matched the old phrasing, so _handle_trust_prompt
stopped auto-accepting and a Codex worker hangs on the unanswered trust
prompt the first time it opens an untrusted directory. In a handoff/assign
flow the supervisor then blocks forever. get_status (which shares the pattern)
also stopped classifying the dialog as WAITING_USER_ANSWER.

Change

• Broaden TRUST_PROMPT_PATTERN (providers/codex.py) to match both the old
  and the 0.144.1 wording, with a comment explaining the version drift.
• The welcome-banner pattern (OpenAI Codex) is still valid on 0.144.1 and is
  left unchanged.

Tests

• New test_handle_trust_prompt_detected_and_accepted_new_wording — the 0.144.1
  dialog is detected and auto-accepted (Enter sent).
• New test_get_status_trust_prompt_new_wording_is_waiting_user_answer — the
  reworded dialog reports WAITING_USER_ANSWER.
• Existing old-wording trust-prompt tests still pass (110 passed).

Verification

Launched a Codex worker via CAO in a fresh untrusted directory on codex-cli
0.144.1: with the fix, CAO auto-accepts the trust dialog and Codex proceeds to
answer (Mean: 8) within ~5s, instead of hanging at the prompt.

[anilkmr-a2z]

LGTM. Regex alternation correctly matches both old and new trust-dialog wording. Tests cover both code paths (_handle_trust_prompt auto-accept + get_status classification). Clean, well-scoped fix.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
⚠️ Please upload report for BASE (main@29f175c). Learn more about missing BASE report.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #411   +/-   ##
=======================================
  Coverage        ?   87.90%           
=======================================
  Files           ?      123           
  Lines           ?    15648           
  Branches        ?        0           
=======================================
  Hits            ?    13756           
  Misses          ?     1892           
  Partials        ?        0           

Flag	Coverage Δ
unittests	87.90% <100.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Copilot]

Pull request overview

This PR updates the Codex provider’s workspace-trust detection so CAO continues to auto-accept the trust dialog after codex-cli 0.144.1 reworded the prompt, preventing worker startup hangs and restoring correct WAITING_USER_ANSWER classification.

Changes:

• Broaden TRUST_PROMPT_PATTERN to match both the legacy “allow Codex…” phrasing and the newer “Do you trust the contents of this directory?” wording.
• Add unit tests covering auto-accept behavior and get_status() classification for the new trust-dialog wording.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/cli_agent_orchestrator/providers/codex.py	Expands the trust-prompt regex (with explanatory comment) so _handle_trust_prompt() and get_status() detect both old and new codex-cli trust dialog text.
test/providers/test_codex_provider_unit.py	Adds tests to ensure the reworded trust prompt is detected/auto-accepted and classified as WAITING_USER_ANSWER.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[haofeif]

@SparkyWen can you please help to fix the CI check failures? many thanks

[gutosantos82]

PR Review: #411 — fix(codex): match reworded trust dialog on codex-cli 0.144.1 (#410)

Summary

Broadens TRUST_PROMPT_PATTERN in providers/codex.py so CAO keeps auto-accepting
Codex's workspace-trust dialog after codex-cli 0.144.1 reworded it ("Do you trust the
contents of this directory?"). The fix is correct, minimal, and well-tested — both the
_handle_trust_prompt auto-accept path and the get_status classification path are
covered, with the old wording retained as a regression guard. One blocker: the new
code is not black-formatted, which reproduces the CI failure a maintainer already
reported. A single black autoformat commit unblocks it. Recommend request changes
until CI is green.

Blocking (must fix before merge)

• [verification/conventions] src/cli_agent_orchestrator/providers/codex.py:82-88 — 🆕
  black --check src/ test/ (the exact CI command) fails: "1 file would be reformatted:
  codex.py". The two implicitly-concatenated r"..." string literals are split across
  lines, but they fit within 88 cols, so black wants them joined. This is the CI failure
  @haofeif asked the author to fix. Fix: uv run black src/cli_agent_orchestrator/providers/codex.py and commit. (introduced; core providers/
  path — weighted up to blocking since it keeps CI red.)

Important (should fix)

None. The functional change is sound.

Nits (optional)

• [correctness/security] src/cli_agent_orchestrator/providers/codex.py:84-87 — The new
  branch Do you trust the contents of this (?:directory|folder) is generic English,
  matched via re.search over the whole clean-output buffer in get_status() (:452),
  not just the tail. On this repo especially (agents discuss/echo the codex trust dialog and
  issue #410), that phrase could land in the pane buffer and cause a spurious
  WAITING_USER_ANSWER. Impact is bounded: the auto-Enter only fires in _handle_trust_prompt
  during initialize() over a ~20s startup window (not mid-session), so attacker/model
  content later can only mislabel status, not trigger an unwanted trust accept. Optional
  hardening: anchor the new branch to its menu context (e.g. require the adjacent
  › 1. Yes / No, quit option line) or restrict the trust scan to the tail. (introduced;
  raised independently by both the correctness and security reviewers.)
• [consistency/tests] src/cli_agent_orchestrator/providers/codex.py:86 — The
  (?:directory|folder) alternation adds a "folder" variant that was never observed in
  either documented codex-cli version; the PR body and the code comment only justify
  "directory". It's harmless defensive matching but is undocumented drift, and no test
  exercises the "folder" branch. Either add a one-line note that "folder" is a defensive
  guess (or drop it), and/or add a folder-variant test case to cover the alternation fully.
• [correctness] src/cli_agent_orchestrator/providers/codex.py:84-87 — Pattern is
  case-sensitive (no re.IGNORECASE). Matches 0.144.1 exactly, so no current bug, but it's
  the same fragility class the new comment warns about — a future capitalization tweak would
  silently stop matching. Pre-existing style; optional to harden.

Tests

Adequate. New tests test_handle_trust_prompt_detected_and_accepted_new_wording and
test_get_status_trust_prompt_new_wording_is_waiting_user_answer directly exercise both
changed code paths (auto-accept → send_special_key Enter; classification →
WAITING_USER_ANSWER). Fixtures faithfully reproduce the 0.144.1 dialog (injection warning

• numbered options). Old-wording tests are retained as regression guards, so both
  alternation branches for the original phrasing stay covered, and a negative early-return
  case exists. Style matches the suite. Only gap: the "folder" variant of the new branch is
  untested (see nit above).

Verification

Runs in Docker (uv, python3.12) against the PR head (833ae48).

• Baseline tests — ✓ VERIFIED: uv run pytest test/providers/test_codex_provider_unit.py -q
  → 110 passed in 10.02s. Matches the PR body's "110 passed" claim exactly.
• 2 new tests pass — ✓ VERIFIED: pytest ... -k new_wording → 2 passed, 108 deselected.
• CI failure — ✗ REFUTED (failure reproduced): uv run black --check src/ test/ →
  1 file would be reformatted: src/cli_agent_orchestrator/providers/codex.py. This is the
  reported CI blocker. See Blocking.
• isort — ✓ clean: uv run isort --check-only src/ test/ reports no changes.
• mypy — ⁇ pre-existing only: uv run mypy src/ shows 7 errors, all in files this PR
  does NOT touch (services/status_monitor.py, services/memory_service.py, api/main.py);
  codex.py has zero. Not introduced by #411.
• flake8/ruff: not used by the project.

Prior feedback (already raised — not restating)

• ↩︎ CI check failures — already flagged by @haofeif ("can you please help to fix the CI
  check failures?"); we concur and the verifier pinpointed the cause (black on codex.py). Kept
  in Blocking because it gates merge, but credit is the maintainer's.
• ↩︎ LGTM on the regex correctness — @anilkmr-a2z already confirmed the alternation matches
  both wordings and tests cover both paths; our correctness review concurs.

Verdict

Request changes — the fix is correct and well-tested, but black --check fails on
codex.py (the maintainer-reported CI failure). One black autoformat commit makes it
mergeable; the nits (whole-buffer false-positive risk, undocumented "folder" branch) are
optional. Conventions review did not return; its scope (formatting/lint) was covered by the
verifier's reproduction of the black failure.