[Bug] Codex worker hangs on codex-cli 0.144.1: trust-prompt auto-accept pattern is stale

[SparkyWen]

Summary

CAO's Codex provider auto-accepts the codex-cli workspace-trust dialog by matching a single hard-coded phrase. codex-cli 0.144.1 reworded that dialog, so the pattern no longer matches, the auto-accept never fires, and a Codex worker hangs on the unanswered trust prompt the first time it opens a directory Codex hasn't been trusted for.

Environment

• codex-cli 0.144.1
• src/cli_agent_orchestrator/providers/codex.py

Steps to reproduce

1. Launch a Codex agent/worker in a directory Codex has not been trusted for yet (e.g. cao launch --provider codex --working-directory /tmp/fresh, or any cross-provider handoff/assign that spawns a Codex worker in a new dir).
2. Codex shows its first-run trust dialog:

   > You are in /tmp/fresh
     Do you trust the contents of this directory? Working with untrusted contents comes
     with higher risk of prompt injection. Trusting the directory allows project-local
     config, hooks, and exec policies to load.
   › 1. Yes, continue
     2. No, quit
     Press enter to continue
   

3. CAO's _handle_trust_prompt never recognises this text, times out, and never sends Enter.

Expected

CAO auto-accepts the trust dialog (as it does on older codex-cli) and the worker proceeds.

Actual

The worker sits at the trust dialog and exits without running. In a handoff/assign flow the supervisor then blocks forever waiting for a worker that produced nothing.

Root cause

codex.py matches only the old wording:

TRUST_PROMPT_PATTERN = r"allow Codex to work in this folder"

codex-cli 0.144.1's dialog reads "Do you trust the contents of this directory?" — no overlap. So both _handle_trust_prompt (auto-accept) and get_status (which uses the same pattern to report WAITING_USER_ANSWER) stop recognising the dialog. The welcome-banner pattern (OpenAI Codex) is still correct on 0.144.1, so only the trust pattern is affected.

Fix

Broaden TRUST_PROMPT_PATTERN to match both the old and the 0.144.1 wording (PR to follow). This is the class of bug where a UI-text-coupled regex silently stops matching on a CLI update; matching both phrasings (plus a comment) reduces the chance the next rewording re-breaks it.