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

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_

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

Powered by Codex Action

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

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

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 👍

docs(codex): record the worker-death investigation and its residual

Navigation Menu

Repository navigation

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

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

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

Root Cause

Proposed Fix

Key Changes

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

Root Cause

Fix

Key Code Change

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

Activity

github-actions commented on May 22, 2026

jshaofa-ui commented on May 22, 2026

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

Root Cause

Proposed Fix

Key Changes

jshaofa-ui commented on May 22, 2026

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

Root Cause

Fix

Key Code Change

w2jmoe commented on May 27, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions