[Bug] Codex /compact stays active after app-server exits

[ladydd]

Affected area

Agent runtime / ACP, observed in the desktop app.

Installation method

Built from source.

Lody version or commit

The original desktop reproduction reported LodyOSS 0.76.0 with Codex adapter 9b4c961. Independent confirmation used the rebuilt adapter bundle from Lody checkout 7d6952f3, with adapter fc91dce and Core 0.1.2. That bundle includes the earlier fork fix but predates the compaction fix in adapter #38.

Operating system

Ubuntu 24.04.3 LTS, Linux 6.8.0-138-generic, x86_64.

Agent or runtime

Codex CLI / app-server 0.153.4. The independent protocol reproduction used the real Codex process and a local synthetic model HTTP endpoint.

What happened?

If the Codex app-server exits after acknowledging thread/compact/start, the adapter keeps waiting for a compaction completion event. The ACP prompt does not settle and continues occupying the session. Clicking Stop does not settle it either; a subsequent message is rejected with A Codex prompt is already active.

The original desktop observation lasted about 185 seconds until Stop was clicked. Independent fault injection reproduced the unresolved request and the rejected follow-up. Healthy /compact completes. Ordinary turns already return an internal error when the same native process exits.

This report does not claim data loss or that every recovery mechanism fails. In an independent protocol check, explicitly closing the session settled the original prompt as cancelled, although that close request itself reported a disposed connection.

What did you expect?

When the native process exits, the compaction prompt should return an error and release its active-request state. The host can then use its existing adapter restart and session-load recovery path so the conversation can continue.

How can we reproduce it?

1. Start an isolated Lody/Codex test session and complete one ordinary message.
2. Send /compact and confirm that thread/compact/start has returned its successful acknowledgment while compaction is still running.
3. In the controlled test, terminate only that session's own Codex app-server process. The independent probe verifies its parent PID and executable before injecting the exit; it leaves other application instances alone.
4. Observe that the original ACP prompt stays pending and the desktop continues to show compaction.
5. Send Stop/cancel and then another ordinary message. The next request returns already active while the original request remains unresolved.

How often does it happen?

Every time in the controlled post-start process-exit reproductions. Normal healthy compaction succeeds. The frequency of native process exits in ordinary use was not measured.

Relevant log output

Protocol outcomes, summarized without captured conversation content:

thread/compact/start -> successful acknowledgment
Codex app-server -> process exits
original ACP session/prompt -> remains pending
session/cancel -> original prompt still pending
next session/prompt -> -32600, A Codex prompt is already active

Additional context

• Adapter fix: LodyAI/acp-extension-codex#38, commit 35ca9a1. It rejects compaction waiters on connection close/dispose and handles start-request failure and cleanup.
• Host integration: #551, which depends on adapter Fix/electron local file browser #38 and closes this issue.
• Independent acceptance of the patch: real Codex process exit during compaction returned ACP -32603 in 10ms; the prompt released its active state. After restarting the adapter and loading the original session, history replay, an ordinary message, and another compaction completed. This is protocol/process verification, not a new desktop GUI end-to-end run.
• Related reports were checked: #267 and adapter #30 concern cancellation during compaction; #530 concerns interruption feedback and recovery more broadly. This report isolates native process exit after the compaction start acknowledgment. It does not claim those reports have the same cause or are all fixed by Fix/electron local file browser #38.
• The separate fork-subscription hang was addressed by #544 and adapter feat: upgrade public workspace to React 19 #37; this compaction failure was independently reproduced with that fork fix present.
• Investigated and authored with AI coding agents. The public report contains technical summaries and synthetic test outcomes, not captured user conversations or private source.

Before submitting

• I searched the existing issues and did not find a duplicate.
• This report concerns an open-source component in this repository, not a hosted service, Web or mobile app, account, or billing issue.
• This is not a security vulnerability; security reports follow the repository's security policy.
• I removed credentials, private source, conversations, prompts, personal data, and other sensitive information.