Remote compact task fails with "array too long" error after upgrading to 0.132.0

Resolved 💬 16 comments Opened May 20, 2026 by XaaT Closed Jun 5, 2026

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

What version of Codex CLI is running?

codex-cli 0.132.0

What subscription do you have?

Business

Which model were you using?

gpt-5.5

What platform is your computer?

Linux fedora 7.0.4-200.fc44.x86_64

What terminal emulator and version are you using (if applicable)?

terminal (gui Gnome)

Codex doctor report

{
  "schemaVersion": 1,
  "generatedAt": "1779284857s since unix epoch",
  "overallStatus": "ok",
  "codexVersion": "0.132.0",
  "checks": {
    "app_server.status": {
      "id": "app_server.status",
      "category": "app-server",
      "status": "ok",
      "summary": "background server is not running",
      "details": {
        "control socket": "/home/clement/.codex/app-server-control/app-server-control.sock",
        "daemon state dir": "/home/clement/.codex/app-server-daemon",
        "mode": "ephemeral",
        "pid file": "/home/clement/.codex/app-server-daemon/app-server.pid (missing)",
        "settings": "/home/clement/.codex/app-server-daemon/settings.json (missing)",
        "status": "not running",
        "update-loop pid file": "/home/clement/.codex/app-server-daemon/app-server-updater.pid (missing)"
      },
      "remediation": null,
      "durationMs": 0
    },
    "auth.credentials": {
      "id": "auth.credentials",
      "category": "auth",
      "status": "ok",
      "summary": "auth is configured",
      "details": {
        "auth file": "/home/clement/.codex/auth.json",
        "auth storage mode": "File",
        "stored API key": "false",
        "stored ChatGPT tokens": "true",
        "stored agent identity": "false",
        "stored auth mode": "chatgpt"
      },
      "remediation": null,
      "durationMs": 0
    },
    "config.load": {
      "id": "config.load",
      "category": "config",
      "status": "ok",
      "summary": "config loaded",
      "details": {
        "CODEX_HOME": "/home/clement/.codex",
        "config.toml": "/home/clement/.codex/config.toml",
        "config.toml parse": "ok",
        "cwd": "/work/xaat/redface2",
        "enabled feature flags": "shell_tool, unified_exec, shell_snapshot, terminal_resize_reflow, sqlite, hooks, enable_request_compression, multi_agent, apps, tool_search, tool_suggest, plugins, plugin_hooks, in_app_browser, browser_use, browser_use_external, computer_use, plugin_sharing, image_generation, skill_mcp_dependency_install, steer, guardian_approval, collaboration_modes, tool_call_mcp_elicitation, personality, fast_mode, tui_app_server, workspace_dependencies",
        "feature flag overrides": "none",
        "feature flags enabled": "28",
        "log dir": "/home/clement/.codex/log",
        "mcp servers": "2",
        "model": "gpt-5.5",
        "model provider": "openai",
        "sqlite home": "/home/clement/.codex"
      },
      "remediation": null,
      "durationMs": 0
    },
    "installation": {
      "id": "installation",
      "category": "install",
      "status": "ok",
      "summary": "installation looks consistent",
      "details": {
        "PATH codex #1": "/home/linuxbrew/.linuxbrew/bin/codex",
        "current executable": "/home/linuxbrew/.linuxbrew/Caskroom/codex/0.132.0/codex-x86_64-unknown-linux-musl",
        "install context": "other",
        "managed by bun": "false",
        "managed by npm": "false",
        "managed package root": "not set"
      },
      "remediation": null,
      "durationMs": 11
    },
    "mcp.config": {
      "id": "mcp.config",
      "category": "mcp",
      "status": "ok",
      "summary": "MCP configuration is locally consistent",
      "details": {
        "configured servers": "2",
        "disabled servers": "0",
        "stdio servers": "1",
        "streamable_http servers": "1"
      },
      "remediation": null,
      "durationMs": 532
    },
    "network.env": {
      "id": "network.env",
      "category": "network",
      "status": "ok",
      "summary": "network-related environment looks readable",
      "details": {
        "proxy env vars": "none"
      },
      "remediation": null,
      "durationMs": 0
    },
    "network.provider_reachability": {
      "id": "network.provider_reachability",
      "category": "reachability",
      "status": "ok",
      "summary": "active provider endpoints are reachable over HTTP",
      "details": {
        "ChatGPT base URL": "https://chatgpt.com/backend-api/ reachable (HTTP 404)",
        "reachability mode": "ChatGPT auth"
      },
      "remediation": null,
      "durationMs": 206
    },
    "network.websocket_reachability": {
      "id": "network.websocket_reachability",
      "category": "websocket",
      "status": "ok",
      "summary": "Responses WebSocket handshake succeeded",
      "details": {
        "DNS": "2 IPv4, 2 IPv6, first IPv6",
        "auth mode": "chatgpt",
        "connect timeout": "15000 ms",
        "endpoint": "wss://chatgpt.com/backend-api/<redacted>",
        "handshake result": "HTTP 101 Switching Protocols",
        "model provider": "openai",
        "models etag present": "true",
        "provider name": "OpenAI",
        "proxy env vars": "none",
        "reasoning header": "false",
        "server model present": "false",
        "supports websockets": "true",
        "wire API": "responses"
      },
      "remediation": null,
      "durationMs": 646
    },
    "runtime.provenance": {
      "id": "runtime.provenance",
      "category": "runtime",
      "status": "ok",
      "summary": "running local build on linux-x86_64",
      "details": {
        "commit": "unknown",
        "current executable": "/home/linuxbrew/.linuxbrew/Caskroom/codex/0.132.0/codex-x86_64-unknown-linux-musl",
        "install method": "other",
        "platform": "linux-x86_64",
        "version": "0.132.0"
      },
      "remediation": null,
      "durationMs": 0
    },
    "runtime.search": {
      "id": "runtime.search",
      "category": "search",
      "status": "ok",
      "summary": "search is OK (system)",
      "details": {
        "search command": "rg",
        "search command readiness": "ripgrep 15.1.0",
        "search provider": "system"
      },
      "remediation": null,
      "durationMs": 30
    },
    "sandbox.helpers": {
      "id": "sandbox.helpers",
      "category": "sandbox",
      "status": "ok",
      "summary": "sandbox configuration is readable",
      "details": {
        "approval policy": "OnRequest",
        "codex-linux-sandbox helper": "/home/clement/.codex/tmp/arg0/codex-arg0Q8CGvk/codex-linux-sandbox",
        "execve wrapper helper": "/home/clement/.codex/tmp/arg0/codex-arg0Q8CGvk/codex-execve-wrapper",
        "filesystem sandbox": "restricted",
        "network sandbox": "restricted"
      },
      "remediation": null,
      "durationMs": 0
    },
    "state.paths": {
      "id": "state.paths",
      "category": "state",
      "status": "ok",
      "summary": "state paths and databases are inspectable",
      "details": {
        "CODEX_HOME": "/home/clement/.codex (dir)",
        "active rollout files": "26 files, 125758207 total bytes, 4836854 average bytes",
        "archived rollout files": "0 files, 0 total bytes, 0 average bytes",
        "log DB": "/home/clement/.codex/logs_2.sqlite (file)",
        "log DB integrity": "ok",
        "log dir": "/home/clement/.codex/log (dir)",
        "sqlite home": "/home/clement/.codex (dir)",
        "state DB": "/home/clement/.codex/state_5.sqlite (file)",
        "state DB integrity": "ok"
      },
      "remediation": null,
      "durationMs": 143
    },
    "terminal.env": {
      "id": "terminal.env",
      "category": "terminal",
      "status": "ok",
      "summary": "terminal metadata was detected",
      "details": {
        "COLORTERM": "truecolor",
        "DISPLAY": "present",
        "WAYLAND_DISPLAY": "present",
        "color output": "enabled",
        "effective locale": "fr_FR.UTF-8",
        "stderr is terminal": "true",
        "stdin is terminal": "true",
        "stdout is terminal": "true",
        "terminal": "VTE",
        "terminal size": "212x49",
        "terminal version": "8400"
      },
      "remediation": null,
      "durationMs": 0
    },
    "updates.status": {
      "id": "updates.status",
      "category": "updates",
      "status": "ok",
      "summary": "update configuration is locally consistent",
      "details": {
        "cached latest version": "0.131.0",
        "check for update on startup": "true",
        "last checked at": "2026-05-19T18:44:55.329472922Z",
        "latest version": "0.132.0",
        "latest version status": "current version is not older",
        "update action": "manual or unknown",
        "version cache": "/home/clement/.codex/version.json"
      },
      "remediation": null,
      "durationMs": 310
    }
  }
}

What issue are you seeing?

Description

After upgrading Codex CLI from 0.130.0 to 0.132.0, the remote compact task fails with an array_above_max_length error from the API. The conversation array exceeds the maximum allowed length of 16384 items.

This did not occur on 0.130.0 with the same usage pattern.

Actual behavior

The compact task fails with the following error:

``■ Error running remote compact task: { "error": { "message": "Invalid 'input': array too long. Expected an array with maximum length 16384, but got an array with length 19300 instead.", "type": "invalid_request_error", "param": "input", "code": "array_above_max_length" } }``

The session is then stuck — compaction cannot succeed and the conversation cannot continue cleanly.

What steps can reproduce the bug?

Upgrade Codex CLI from 0.130.0 to 0.132.0
Use Codex normally until the conversation grows large enough to trigger an auto-compact
Observe the remote compact task failing

What is the expected behavior?

The remote compact task should successfully reduce the conversation size, or the client should pre-emptively trim/split the input to stay within the API's 16384-item array limit before sending the compact request.

Additional information

_No response_

View original on GitHub ↗

16 Comments

github-actions[bot] contributor · 2 months ago

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

#23589
#22890
#23263

Powered by Codex Action

jshaofa-ui · 2 months ago

Proposed Solution: Streaming Compression + Size Pre-check + Smart Degradation

Root Cause

v0.132.0 changed from chunk-based serialization to one-shot serialization of entire conversation history. Long conversations (>2GB estimated) trigger Buffer.alloc() "array too long" error. No size pre-check or degradation strategy exists.

Recommended Fix (Option B)

Pre-check: estimateSize() before compression, auto-select strategy
Fast path (<1MB): one-shot compression
Chunked path (1-10MB): 64KB chunk compression
Streaming path (10-100MB): streaming compression, no large Buffer allocation
Selective path (>100MB): compress old messages, keep recent 20 uncompressed

Key Changes

src/compression/size-estimator.ts: estimateCompressionStrategy() with 4-tier strategy
src/compression/streaming-compressor.ts: StreamingCompressor (chunk/stream/selective)
src/tasks/remote-compact-task.ts: strategy-aware RemoteCompactTask

Testing Plan

6 unit tests + 5 integration tests
Handles conversations up to 100K messages
Backward compatible with v0.131.0 compression format
Compression success rate: 0% → 100%
Implementation: 3-4 days

Full solution document available with complete code examples. Happy to discuss further.

XaaT · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate. - #23589 - #22890 - #23263 Powered by Codex Action

Close but not the same.

Keesan12 · 2 months ago

An "array too long" failure on remote compaction feels like the compact step is still assembling a full-fidelity payload before the cap is enforced.

The safer pattern is to budget during assembly, not after. Once the remote task builds the oversized array, you have already paid the coordination cost and lost the chance to emit a useful receipt about what was kept vs dropped. A compact pipeline that carries item count and byte budget as first-class fields is much easier to debug.

XaaT · 2 months ago

Downgraded to 0.131.0 and working again
brew remove codex
npm i -g @openai/codex@0.131.0

dearlordylord · 2 months ago

Can confirm, 0.131.0 works and doesn't exhibit this compaction bug

Keesan12 · 2 months ago

The downgrade data point helps narrow this quite a bit: if 0.131.0 works and 0.132.0 trips array too long, the critical invariant is that strategy selection has to happen before the compact path materializes a full payload.

The debugging receipt I would want from the remote compact task is:

total_items_seen
estimated_bytes_before_compact
chosen_compaction_strategy
items_compacted
items_left_inline
truncation_or_drop_reason

Then a failure tells you whether the budget decision was wrong, or whether the chosen strategy ignored the budget and still built the oversized array anyway.

amp42 · 1 month ago

Long conversations (>2GB estimated)

@jshaofa-ui not sure it's that large. How do I check how much it attempted to compact?

XaaT · 1 month ago

shame again with next version 0.133.0

■ Error running remote compact task: {
  "error": {
    "message": "Invalid 'input': array too long. Expected an array with maximum length 16384, but got an array with length 21740 instead.",
    "type": "invalid_request_error",
    "param": "input",
    "code": "array_above_max_length"
  }
}

amp42 · 1 month ago

Upgrade Codex CLI from 0.130.0 to 0.132.0

Use Codex normally until the conversation grows large enough to trigger an auto-compact
Observe the remote compact task failing

My update workflow that hit this bug:

Work in a Codex session, letting it auto-compact as it rolls along.
New Codex version is released. Update via npm.
/exit, then codex resume --last ...

XaaT · 1 month ago

Just come back to 0.131.0
npm i -g @openai/codex@0.131.0

Keesan12 · 1 month ago

The fresh 0.133.0 repro plus the resume --last update path makes this look even more like a count-budget problem than a raw byte-size problem.

If anyone on the thread wants the fastest way to narrow it without deep instrumentation, I'd log just four numbers before the remote compact request is sent:

conversation_item_count
items_added_since_last_compact
resume_rehydrated_item_count
target_items_after_compact

That would answer two useful questions quickly:

is the regression happening because resume rehydrates too much old structure back into the live array?
or is compaction choosing a strategy that still leaves the request above the 16384-item cap?

The reason I’d start with item counts rather than byte estimates is that the API failure here is already telling us the contract that matters: array length, not compressed payload size.

If anyone can share those four counts across a working 0.131.0 run and a failing 0.133.0 run, the regression boundary should get much sharper.

diogovalada · 1 month ago

This is very urgent, as it is really breaking. Should be top priority.

paulezack · 1 month ago

I am also hitting this issue in the VS Code/Codex extension.

Error

From the VS Code/Codex UI screenshot:

Error running remote compact task: {
  "error": {
    "message": "Invalid 'input': array too long. Expected an array with maximum length 16384, but got an array with length 19801 instead.",
    "type": "invalid_request_error",
    "param": "input",
    "code": "array_above_max_length"
  }
}

Impact

The Codex thread becomes blocked after automatic context compaction fails. I cannot continue working in the affected project/thread because compaction repeatedly fails instead of reducing the context.

Environment

IDE: VS Code / Codex extension
OS: Windows 11 25H2
Codex extension version: 26.519.32039
VS Code version: 1.121
Model: 5.5 Xhigh
Workspace mode: local repo

Reproduction notes

Work in a long-running Codex thread in VS Code.
Continue until Codex attempts automatic context compaction.
The remote compact task fails with array_above_max_length.
The session cannot continue cleanly.

Expected behavior

Codex should either compact earlier, chunk/trim the compact request, or fall back to a safe local/session-recovery path so that the compact request itself never exceeds the 16384 input-array limit.

Additional notes

This appears to be the same failure mode reported here, but my occurrence is in the VS Code/Codex extension and the failed input array length was 19801.

amp42 · 1 month ago

cli on Linux - Updated to 0.135 and tried to repro, didn't encounter the error.

XaaT · 1 month ago

cli on Linux - Updated to 0.135 and tried to repro, didn't encounter the error.

fine for me aswell now