-
-
Notifications
You must be signed in to change notification settings - Fork 81.9k
Codex app-server client closes before long maintenance turn completes; Gateway restart also terminates active turn without graceful recovery #95547
Copy link
Copy link
Closed
Labels
P1High-priority user-facing bug, regression, or broken workflow.High-priority user-facing bug, regression, or broken workflow.clawsweeper:fix-shape-clearClawSweeper found a clear likely implementation shape for this issue.ClawSweeper found a clear likely implementation shape for this issue.clawsweeper:needs-live-reproClawSweeper needs live local, crabbox, or manual validation to confirm this issue.ClawSweeper needs live local, crabbox, or manual validation to confirm this issue.clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.ClawSweeper marked this issue as needing maintainer review before automation.clawsweeper:needs-product-decisionClawSweeper marked this issue as needing a product or behavior decision.ClawSweeper marked this issue as needing a product or behavior decision.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.ClawSweeper does not recommend queueing a new automated fix PR for this issue.impact:message-lossChannel message delivery can be lost, duplicated, or misrouted.Channel message delivery can be lost, duplicated, or misrouted.impact:session-stateSession, memory, transcript, context, or agent state can drift or corrupt.Session, memory, transcript, context, or agent state can drift or corrupt.issue-rating: 🐚 platinum hermitGood issue quality with a plausible reproduction path needing some confirmation.Good issue quality with a plausible reproduction path needing some confirmation.maturity:stableBroken existing behavior primarily owned by an M4/M5 scorecard surface.Broken existing behavior primarily owned by an M4/M5 scorecard surface.staleMarked as stale due to inactivityMarked as stale due to inactivity
Description
Activity
Metadata
Metadata
Assignees
Labels
P1High-priority user-facing bug, regression, or broken workflow.High-priority user-facing bug, regression, or broken workflow.clawsweeper:fix-shape-clearClawSweeper found a clear likely implementation shape for this issue.ClawSweeper found a clear likely implementation shape for this issue.clawsweeper:needs-live-reproClawSweeper needs live local, crabbox, or manual validation to confirm this issue.ClawSweeper needs live local, crabbox, or manual validation to confirm this issue.clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.ClawSweeper marked this issue as needing maintainer review before automation.clawsweeper:needs-product-decisionClawSweeper marked this issue as needing a product or behavior decision.ClawSweeper marked this issue as needing a product or behavior decision.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.ClawSweeper does not recommend queueing a new automated fix PR for this issue.impact:message-lossChannel message delivery can be lost, duplicated, or misrouted.Channel message delivery can be lost, duplicated, or misrouted.impact:session-stateSession, memory, transcript, context, or agent state can drift or corrupt.Session, memory, transcript, context, or agent state can drift or corrupt.issue-rating: 🐚 platinum hermitGood issue quality with a plausible reproduction path needing some confirmation.Good issue quality with a plausible reproduction path needing some confirmation.maturity:stableBroken existing behavior primarily owned by an M4/M5 scorecard surface.Broken existing behavior primarily owned by an M4/M5 scorecard surface.staleMarked as stale due to inactivityMarked as stale due to inactivity
Type
Fields
Priority
None yet
Summary
During a long maintenance/update task initiated from a messaging channel, the active Codex-backed agent turn failed with:
codex app-server client closed before turn completedThis happened twice in the same maintenance flow:
In both cases the Gateway itself was able to run afterward, but the user-facing turn was lost and the user only saw the generic failure message instead of a graceful status/follow-up.
Environment
2026.6.9 (c645ec4)0.141.0v24.16.0What happened
A user request triggered a long-running maintenance task: OpenClaw update/checks, OS package checks, npm/pipx checks, Codex/Claude version checks, Gateway health checks, and memory checks.
The first long turn failed before a final response:
Later, memory search/status showed the semantic index was dirty and paused, and reindexing initially failed because a reindex lock was held:
A Gateway restart was performed to recover from the stuck/active lock. That restart also terminated the active Codex turn:
The Gateway did come back successfully:
The memory index was later rebuilt successfully:
Expected behavior
For long-running Codex-backed turns, especially maintenance tasks:
codex app-serverexits unexpectedly, OpenClaw should preserve enough task state to provide a useful follow-up or recovery message.Actual behavior
The user received generic failure messages like:
The underlying Gateway was healthy afterward, but the original maintenance status was lost until the user manually asked for status again.
Impact
For maintenance/update operations, this makes the system look broken even when Gateway is still healthy or has restarted successfully. It also leaves the user without a reliable final report unless they manually ask again.
Notes
This may be two related issues:
The memory reindex lock issue may be separate, but it contributed to the recovery flow that triggered the second app-server interruption.