bug: codex-acp Discord session can hang after auto-approved shell escalation

[chihkang]

Description

When running openab with the Codex agent (codex-acp) on Kubernetes, a Discord thread can become permanently stuck after a shell command first fails under the default Codex sandbox/network restrictions and is then retried through the auto-approved escalation path.

In my case, this happened while asking the bot to run:

HOME=/home/node gh issue view 269 -R openabdev/openab

The bot acknowledged the request, then appeared to switch to an elevated path, and never sent a final reply back to Discord.

This appears to be both:

• a documentation gap in the current Codex deployment guide, and
• a runtime/integration bug in the escalation path

Steps to Reproduce

1. Deploy openab with codex-acp using the documented/basic setup from docs/codex.md.
2. Authenticate gh successfully inside the agent container.
3. In Discord, ask the bot to run a GitHub CLI command that needs network access, for example:
   HOME=/home/node gh issue view 269 -R openabdev/openab
4. Observe that the first attempt fails due to GitHub/network access inside the default Codex runtime.
5. Observe that openab auto-allows the follow-up permission/escalation request.
6. The Discord thread never receives a final answer and appears stuck.

Expected Behavior

One of the following should happen:

1. the escalated command completes and the agent replies normally, or
2. the agent returns a clear failure message to Discord

It should not silently hang after an auto-approved escalation.

Environment

• openab chart/app version: 0.7.1
• deployment: Helm on k3s / Kubernetes
• agent: codex-acp
• image: ghcr.io/openabdev/openab-codex:78f8d2c
• working dir: /home/node
• Discord integration enabled
• GitHub CLI (gh) installed and authenticated inside the agent container
• Initial generated Codex config was effectively:

[agent]
command = "codex-acp"
args = []
working_dir = "/home/node"

Screenshots / Logs

Observed signals:

• shell error: error connecting to api.github.com
• openab log showed an auto-allowed permission for the retried command
• the Codex session transcript stopped after the escalated tool call
• no task_complete / final reply was emitted
• in this container/runtime, workspace-write sandboxing also produced:
  bwrap: Failed to make / slave: Permission denied

Additional notes:

• docs/codex.md currently does not explain that Codex sandbox/approval/network settings may need to be configured explicitly for networked shell commands such as gh
• related issues: bug: SessionPool lock scope crosses await and can stall prompt handling #256 and bug: streaming truncation hides agent interaction prompts, causing thread deadlock #242
• I was only able to make this reliable by explicitly setting Codex args in the Helm values and avoiding the problematic interactive escalation path
• this report supersedes bug: codex-acp Discord session can hang after auto-approved shell escalation #285, which was created outside the issue template flow

[CHC-Agent]

Issue at a Glance

User asks bot to run `gh issue view 269`
       │
       ▼
  openab → codex-acp
              │
              ├── 1st attempt: shell exec
              │   ╰─► ❌ sandbox blocks network → "error connecting to api.github.com"
              │
              ├── codex requests escalation (permission prompt)
              │   ╰─► openab auto-approves
              │
              ├── 2nd attempt: escalated shell exec
              │   ╰─► ??? (no task_complete, no error)
              │
              └── Discord thread: ⏳ stuck forever

Hi @chihkang,

Thanks for the detailed report — and for persisting through #281 and #285 to get this properly documented.

Two things going on here:

1. Docs gap: your PR docs: clarify Codex sandbox, approval, network, and AGENTS.md configuration #283 already addresses the missing Codex sandbox/network configuration guidance — that's the right fix for the setup side.

2. Runtime hang: the silent hang after auto-approved escalation needs more investigation. Could you share the codex-acp side logs from when the hang occurs? Specifically, we need to know whether codex itself completed the escalated command (and openab failed to relay the response), or whether codex got stuck too.

Related: #242 (streaming truncation hiding agent prompts) could also contribute to the appearance of a hang if codex emitted a response that got truncated.

[thepagent]

This may be related to the same permission timing race identified in #136.

Investigation in #136 (comment) found that claude-agent-acp self-rejects permission requests in ~14ms before OpenAB's auto-allow reply arrives. The fix for Claude is to set bypassPermissions via settings.json so the adapter never asks.

Worth checking if codex-acp has a similar settings-based permission bypass, or if the hang here is a different state machine issue (session stuck after a successful escalation approval rather than a rejected one).