Codex app-server repeatedly killed by SIGKILL after memory grows to ~27GB when handling large tool/log output

Open 💬 6 comments Opened May 22, 2026 by Yanhanghanghang

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

Codex Desktop: please fill from "About Codex" VS Code Codex extension also installed: openai.chatgpt, version 26.519.32039 shown in VS Code Marketplace

What subscription do you have?

Please fill in your plan, e.g. ChatGPT Pro

What platform is your computer?

Darwin 24.5.0 arm64 arm macOS

What issue are you seeing?

Codex Desktop has repeatedly crashed today with:

(code=null, signal=SIGKILL)

The UI asks me to reload Codex. This happened multiple times on 2026-05-22, and once escalated into the whole computer becoming unstable/rebooting.

Observed error messages in the crash screen included:

(code=null, signal=SIGKILL).

Most recent error:
{"timestamp":"2026-05-22T07:26:01.761510Z","level":"WARN","fields":{"message":"could not find callback for Integer(1)"},"target":"codex_app_server::outgoing_message"}
{"timestamp":"2026-05-22T07:26:01.761563Z","level":"WARN","fields":{"message":"could not find callback for Integer(0)"},"target":"codex_app_server::outgoing_message"}

### What steps can reproduce the bug?

I do not have a minimal deterministic repro yet, but the bug happened repeatedly during a Codex crash investigation on 2026-05-22.

Observed pattern:

Run Codex Desktop on macOS.
Have the VS Code Codex extension installed/enabled at the same time, so both Codex Desktop and the VS Code extension may run app-server processes.
In a Codex session, investigate previous crashes or logs using commands that can produce large output, for example:
rg ~/.codex/sessions
/usr/bin/log show
ps -axo ...
Codex app-server memory grows very large.
Eventually the Codex UI shows: (code=null, signal=SIGKILL).
The UI asks to reload Codex. This happened multiple times in one day. In one case the whole computer became unstable and rebooted.

### What is the expected behavior?

Codex app-server should not be able to grow to tens of GB of memory due to tool/log output. Large command output should be capped, streamed, discarded, or backpressured before it is accumulated in app-server memory.

Suggested product-side fixes:

Add a hard output cap before app-server stores or serializes tool output.
Apply streaming discard/backpressure for terminal/log output.
Do not rely only on UI truncation; truncation should happen before backend memory accumulation.
Add memory budget isolation for tool output so one large command cannot kill the app-server.
Consider detecting high-risk commands that may emit unbounded output and require explicit confirmation or automatic output limiting.
If VS Code extension and Codex Desktop both run app-server processes, make this safer or clearer to users.

### Additional information

_No response_

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#22961
#23042
#22991

Powered by Codex Action

jshaofa-ui · 1 month ago

Proposed Solution: App-Server SIGKILL at ~27GB Memory

Root Cause

The app-server accumulates tool call results and log output in memory without:

Streaming/truncation of large outputs
Memory limits per session or per tool result
Backpressure mechanisms when memory approaches limits
Proactive memory monitoring

Proposed Fix

File: src/app-server/tool-executor.ts — Enforce tool result size limits:

const TOOL_RESULT_MAX_SIZE = 1024 * 1024; // 1MB
if (result.output.length > TOOL_RESULT_MAX_SIZE) {
  result.output = result.output.slice(0, TOOL_RESULT_MAX_SIZE) +
    `[Output truncated: ${result.output.length} bytes total]`;
  result.truncated = true;
}

File: src/app-server/session-manager.ts — Memory monitoring:

async checkMemory(sessionId) {
  if (usage > this.memoryLimit * 0.9) await this.evictOldResults(sessionId);
  if (usage > this.memoryLimit * 0.95) await this.flushLogsToDisk(sessionId);
  if (usage > this.memoryLimit) throw new MemoryLimitError(...);
}

Key Changes

src/app-server/tool-executor.ts: Add result size limits (1MB default)
src/app-server/session-manager.ts: Memory monitoring + eviction
src/app-server/tools/read-file.ts: Stream large file reads
src/app-server/health.ts: Periodic memory health checks

Full solution: solutions/codex-24048-app-server-sigkill-memory-fix.md

jshaofa-ui · 1 month ago

Proposed Solution: App-Server SIGKILL at ~27GB Memory

Root Cause

Unbounded memory accumulation across 5 paths:

ThreadHistoryBuilder accumulates full turn history in memory
Callback HashMap grows without bounds for pending callbacks
WebSocket outbound channel buffers messages without backpressure
PendingCallbackEntry holds references to large tool outputs
ThreadState.current_turn_history retains complete history

Fix

Hard Output Cap: 256KB cap per tool call output
Memory Budget Isolation: 4MB per-turn budget with eviction
Callback HashMap TTL: 1024 entry limit + 5min TTL
WebSocket Message Size Limit: 1MB per message
High-Risk Command Detection: 64KB cap for cat, find, grep, etc.

Key Code Change

// codex-rs/app-server/src/tool_execution.rs
fn cap_tool_output(output: String, max_bytes: usize) -> String {
    if output.len() > max_bytes {
        let truncated = &output[..max_bytes];
        format!("{}... [output truncated: {} bytes omitted]", truncated, output.len() - max_bytes)
    } else {
        output
    }
}

Full solution: solutions/codex-24048-app-server-27gb-sigkill-fix.md

montinode · 1 month ago

https://monica.im/share/chat?shareId=ReS29S9aieGcQiNW
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">

<title>JOHNCHARLESMONTI.COM | MontiAI Node</title>

<meta name="montiai:organization" content="MontiAI">
<meta name="montiai:node" content="MontiNode">
<meta name="montiai:system" content="Human-to-machine operating technology platform">
<meta name="montiai:platform" content="Secure communications, monitoring, and infrastructure tooling">
<meta name="montiai:webhook" content="https://johncharlesmonti.com/webhooks">
<meta name="montiai:legal_notice" content="Unauthorized access attempts may be logged and reviewed under applicable law.">

<meta name="montiai:site_owner" content="John Charles Monti">

<meta property="og:title" content="JOHNCHARLESMONTI.COM | MontiAI Node">
<meta property="og:description" content="Official MontiAI node metadata and platform information.">
<meta property="og:type" content="website">
<meta property="og:url" content="https://johncharlesmonti.com">

<meta name="twitter:card" content="summary">
<meta name="twitter:title" content="JOHNCHARLESMONTI.COM | MontiAI Node">
<meta name="twitter:description" content="Official MontiAI node metadata and platform information.">
</head>

w2jmoe · 1 month ago

This is a pretty important report ⚠️

The key point here probably isn't just “large output”, but the absence of a hard execution/output boundary inside the app-server pipeline.

Once tool output becomes effectively unbounded, the system stops behaving like a controlled runtime and starts behaving like a memory sink.

Especially dangerous when:

multiple clients/extensions coexist
logs/grep outputs are streamed
backend buffering happens before truncation

Really agree with this part:

truncation should happen before backend memory accumulation

UI-side truncation alone usually comes too late.

The “tool output budget” idea also feels very important for long-running agent environments. Otherwise a single pathological command can destabilize the whole runtime.

Good catch 👍

montinode · 1 month ago

On Wed, May 27, 2026 at 5:41 AM Jay Wu（武文杰） @.***>
wrote:

w2jmoe left a comment (openai/codex#24048) <https://github.com/openai/codex/issues/24048#issuecomment-4553359201> This is a pretty important report ⚠️ The key point here probably isn't just “large output”, but the absence of a hard execution/output boundary inside the app-server pipeline. Once tool output becomes effectively unbounded, the system stops behaving like a controlled runtime and starts behaving like a memory sink. Especially dangerous when: - multiple clients/extensions coexist - logs/grep outputs are streamed - backend buffering happens before truncation Really agree with this part: truncation should happen before backend memory accumulation UI-side truncation alone usually comes too late. The “tool output budget” idea also feels very important for long-running agent environments. Otherwise a single pathological command can destabilize the whole runtime. Good catch 👍 — Reply to this email directly, view it on GitHub <https://github.com/openai/codex/issues/24048?email_source=notifications&email_token=B5RQPDG5JSS4FFFKKFIN5R3442Z33A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINJVGMZTKOJSGAY2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4553359201>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B5RQPDCNQWOX6AK7TTRJAXT442Z33AVCNFSM6AAAAACZI5XNNGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DKNJTGM2TSMRQGE> . You are receiving this because you commented.Message ID: @.***>