Remote compaction intermittently fails with stream disconnected before completion

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

• #17335
• #16377
• #16436
• #16281
• #15727

Powered by Codex Action

Close, Restart OS and Run. It should fix it - more detail here: https://github.com/openai/codex/issues/19255#issuecomment-4310146804

Sorry, what is the "root" ticket for this ?
Thanks @RossRichardson for the workaround (didn't tried it yet)

I am seeing the same remote compaction failure repeatedly on a newer CLI version.

Environment:

• Codex CLI: codex-cli 0.125.0
• Install path: npm global package @openai/codex
• Platform: macOS 26.1, Darwin 25.1.0, arm64
• Shell: zsh
• Auth mode: ChatGPT/Codex CLI
• Models observed while retrying: gpt-5.4-mini, gpt-5.4, gpt-5.2, gpt-5.5

Observed error:

Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

Full visible sequence:

Model changed to gpt-5.4-mini medium

Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

Model changed to gpt-5.4 medium

Conversation interrupted - tell the model what to do differently. Something went wrong? Hit `/feedback` to report the issue.

Model changed to gpt-5.2 medium

Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

Model changed to gpt-5.5 xhigh

Impact:

• Once compaction fails, the session becomes hard to continue safely because the conversation is near the context limit.
• Switching models does not resolve it, which suggests the failure is in the remote compact endpoint/path rather than model-specific generation.
• The practical workaround is manual handoff summarization into a new session, but that loses the intended automatic recovery path.

Expected behavior:

• /compact should complete, or
• fail with a retryable/recoverable path that does not interrupt the session, ideally preserving enough state for the user to continue or retry compaction.

This has happened more than once, not a one-off transient failure.

Also seeing this on Codex Desktop for macOS.

Thread ID: 019e0390-d329-74c3-b8ab-13a32d339c9b
Codex App: 26.429.61741 (2429)
Error:

Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

This is still happening today (2026-05-07).

Adding a consolidated signal update here because this issue appears to be the primary tracker for remote compaction failures with stream disconnected before completion.

A recent refresh found several adjacent reports with the same broader failure mechanism: long-running sessions approach the context window, remote compaction starts or is attempted, and the session either fails to compact, hangs, becomes unusable, or loses reliable continuity. Examples I found while de-duplicating include #22309, #22107, #19660, #19558, #19441, #19400, #19386, #18829, #18363, #17802, #14684, #11954, #10986, #9800, and #9198. #18838 also appears to have already been closed as a duplicate of this issue.

The pattern looks broader than a single transient network disconnect. Sanitized local evidence and community reports suggest several useful failure classes:

• stream disconnect during remote compact;
• timeout or missing completion after compact starts;
• compact request becoming too large near the context limit;
• model-specific remote compact risk signals;
• session unusable or repeated-error-loop states after compact failure;
• resume/session continuity issues adjacent to the same long-context recovery path.

Expected upstream behavior, in my view, is not necessarily that every compact always succeeds. The more important recovery invariant is that a failed remote compact should not leave the active thread unrecoverable or stuck in a repeated failure loop.

Concrete improvements that would make reports and recovery much more actionable:

1. Preserve session usability after remote compact failure where possible, or provide a clear recovery path when continuing the same thread is impossible.
2. Expose structured compact lifecycle events: started, request sent, failed, completed, fallback attempted, session marked unrecoverable.
3. Classify failure modes separately instead of collapsing them into a generic compact failure: stream disconnect, timeout/missing completion, context length exceeded, endpoint/model incompatibility, backend high demand, invalid history/client post-processing.
4. Consider model-aware remote compact fallback or safer retry behavior, especially after the same compact path has already failed for the session.

This comment intentionally avoids raw logs, local absolute paths, account IDs, thread IDs, session IDs, and full transcripts.

I am seeing the same issue in the Codex VS Code extension.

Error:
Error running remote compact task: stream disconnected before completion:
error sending request for url
(https://chatgpt.com/backend-api/codex/responses/compact)

It happens for both:

• manual compaction
• automatic compaction when the thread becomes long

This has been recurring for me for more than 20 days.

Observed local log dates:

• 2026-05-01
• 2026-05-02
• 2026-05-12
• 2026-05-13
• 2026-05-17
• 2026-05-21

Relevant local logs show:
target=codex_core::compact_remote

Examples:

• 2026-05-21:

last_api_response_total_tokens=216558
failing_compaction_request_model_visible_bytes=947276

• 2026-05-17:

last_api_response_total_tokens=221908
failing_compaction_request_model_visible_bytes=995111

Environment:

• Codex used through VS Code extension
• VS Code on Windows
• Workspace opened in WSL
• Remote extension installed in WSL:

openai.chatgpt-26.513.21555-linux-x64

• Local Codex CLI currently reports:

codex-cli 0.130.0

I also tried increasing:
stream_idle_timeout_ms = 900000

That setting was applied on 2026-05-08, but compaction failures continued afterward.

I updated Codex CLI and reproduced the issue again manually in Codex TUI.

Latest reproduction:

• Date: 2026-05-22 11:55:11 Asia/Shanghai
• Codex CLI version: 0.133.0
• Trigger: manual /compact in Codex CLI
• Log target: codex_core::compact_remote
• Endpoint: /responses/compact
• Error:

stream disconnected before completion:
error sending request for url
(https://chatgpt.com/backend-api/codex/responses/compact)

Relevant log details:

• originator=codex-tui
• app.version=0.133.0
• attempt=4
• duration_ms=33049
• last_api_response_total_tokens=216558
• failing_compaction_request_model_visible_bytes=947276

The compact task itself ran for about 168 seconds before failing.

Adding another current reproduction from Codex CLI with the same failure signature.

Environment:

• Codex CLI: 0.133.0
• Platform: Linux x86_64
• Install: npm global package @openai/codex
• Auth mode: ChatGPT
• Model: gpt-5.5 with high reasoning
• codex doctor: install/auth/state/websocket healthy, 13 ok, 0 fail
• Websocket check: HTTP 101 Switching Protocols
• Proxy env vars: none

Observed behavior:

• Normal turns and tool execution continue to work.
• Failure appears specifically when remote compaction is triggered near the context limit.
• The thread becomes effectively unusable after the compaction failure, which is a serious regression for long-running technical/scientific sessions.

Repeated local log examples:

2026-05-19T21:25:13Z compact_remote failed
  last_api_response_total_tokens=236193
  failing_compaction_request_model_visible_bytes=830827
  compact_error=stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

2026-05-21T00:26:13Z compact_remote failed
  last_api_response_total_tokens=224924
  failing_compaction_request_model_visible_bytes=905866
  compact_error=stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

2026-05-21T19:24:27Z compact_remote failed
  last_api_response_total_tokens=234388
  failing_compaction_request_model_visible_bytes=846151
  compact_error=stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

2026-05-22T05:47:20Z compact_remote failed
  last_api_response_total_tokens=229984
  failing_compaction_request_model_visible_bytes=875864
  compact_error=stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

2026-05-22T05:54:10Z compact_remote failed again on the same thread
  last_api_response_total_tokens=229984
  failing_compaction_request_model_visible_bytes=875864
  compact_error=stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

Notes:

• This does not look like a general local install/auth failure; doctor and websocket checks pass.
• It also does not behave like ordinary latency trouble; regular turns can keep working while compaction fails.
• The failing payloads here are around 830-906 KB model-visible history and around 225k-236k prior response tokens.

Expected recovery behavior:

• Remote compaction should be retried or resumed idempotently.
• If remote compaction cannot complete, Codex should preserve the thread and provide a recoverable local/session handoff instead of breaking the working thread.
• For long-running research work, manual checkpointing is not a viable substitute for reliable compaction because it adds substantial token and workflow overhead.

Adding another current macOS datapoint with local logs, since this is now happening constantly on long Codex Desktop threads across multiple repos/dev environments.

Environment:

• Codex Desktop: 26.519.41501, build 3044
• Bundled Codex CLI: 0.133.0-alpha.1
• macOS: 26.5, build 25F71, x86_64
• App signature/notarization: accepted, Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2), stapled ticket
• Auth mode in compact request logs: ChatGPT; auth header attached
• Model in failing examples: gpt-5.5, high or xhigh reasoning

Observed pattern:

• Failures occur during remote compaction near the 258,400-token context window, not during repo-specific shell/tool work.
• The same error appears across different repos and local/remote dev environments.
• Recent local SQLite logs show repeated failures over May 26-28, 2026. Sanitized examples:

2026-05-28 08:55:10Z remote compaction failed model=gpt-5.5 reasoning=high last_api_response_total_tokens=215392 all_history_items_model_visible_bytes=890299 estimated_tokens_added_since_last_successful_api_response=20806 model_context_window_tokens=258400 failing_compaction_request_model_visible_bytes=911646 compact_error=stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)
2026-05-27 16:45:48Z remote compaction failed model=gpt-5.5 reasoning=high last_api_response_total_tokens=240136 all_history_items_model_visible_bytes=863506 estimated_tokens_added_since_last_successful_api_response=58 model_context_window_tokens=258400 failing_compaction_request_model_visible_bytes=884853 compact_error=stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)
2026-05-27 16:23:55Z remote compaction failed model=gpt-5.5 reasoning=xhigh last_api_response_total_tokens=227937 all_history_items_model_visible_bytes=785789 estimated_tokens_added_since_last_successful_api_response=129 model_context_window_tokens=258400 failing_compaction_request_model_visible_bytes=807136 compact_error=stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

Request timing from trace-safe log lines:

• /responses/compact failures are after multiple attempts; examples show attempt=4 with duration_ms around 62,936 ms and 74,191 ms.
• Local direct unauthenticated POST probe to the compact endpoint reaches Cloudflare/OpenAI and returns expected HTTP 401 Unauthorized with an x-oai-request-id, so this does not look like local DNS/firewall inability to reach chatgpt.com.

I have not attached full logs because they include private prompt/thread content, but the sanitized numeric telemetry above is directly from ~/.codex/logs_2.sqlite. This looks like the same remote compact stream disconnect issue, currently reproducible on the latest installed macOS app line here.

Adding a current Linux CLI datapoint after updating to Codex CLI 0.135.0.

Environment:

• Codex CLI: 0.135.0 via npm
• Platform: Linux x86_64
• Auth mode: ChatGPT
• Model: gpt-5.5, xhigh reasoning
• codex doctor: healthy; websocket check passes; no proxy env vars
• codex features list: remote_compaction_v2 is under development false

Observed behavior:

• The default compaction path still uses /responses/compact.
• A remote compact attempt retried attempts 0 through 4.
• Each attempt failed after roughly 60-61 seconds with:

error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

• Final compact error:

stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

Final failure telemetry:

• last_api_response_total_tokens=237419
• all_history_items_model_visible_bytes=801190
• failing_compaction_request_model_visible_bytes=822537
• model_context_window_tokens=Some(258400)
• estimated_tokens_of_items_added_since_last_successful_api_response=60

Why this may be useful:

• This reproduction is after the merged v2 retry work, but the default feature state still appears to use the legacy compact endpoint.
• The failure shape looks like a roughly 60-second request/stream cutoff on a near-limit compact payload, not a local auth/connectivity failure.
• Since remote_compaction_v2=false, the v2 retry/fallback fixes may not cover this default path.

This comment intentionally omits account IDs, email addresses, local paths, thread IDs, raw logs, and transcript content.

Codex Desktop remote compaction failures on Windows

Summary

Codex Desktop repeatedly fails when automatic remote context compaction is triggered for long-running threads.

Visible error:

Error running remote compact task: stream disconnected before completion:
error sending request for url
(https://chatgpt.com/backend-api/codex/responses/compact)

This interrupts active work and can make long-running threads unusable.

Environment

• Platform: Windows 11 Professional, x64
• Codex Desktop package: 26.527.3686.0
• Bundled Codex CLI: 0.135.0-alpha.1
• Authentication mode: ChatGPT
• Model provider: openai
• Model: gpt-5.5
• remote_compaction_v2: under development false

Reproduction pattern

1. Work in a long-running Codex Desktop thread until the context approaches the model window.
2. Allow automatic remote compaction to start.
3. The request to /backend-api/codex/responses/compact fails with stream disconnected before completion.
4. Retrying work in the affected thread triggers the same failure again.

Sanitized local evidence

The local Codex SQLite logs contain four codex_core::compact_remote failures on May 31, 2026:

2026-05-31T18:39:01Z
last_api_response_total_tokens=228794
all_history_items_model_visible_bytes=944541
estimated_tokens_of_items_added_since_last_successful_api_response=6968
failing_compaction_request_model_visible_bytes=966015
model_context_window_tokens=258400

2026-05-31T19:58:10Z
last_api_response_total_tokens=241526
all_history_items_model_visible_bytes=781135
estimated_tokens_of_items_added_since_last_successful_api_response=4271
failing_compaction_request_model_visible_bytes=797454
model_context_window_tokens=258400

2026-05-31T20:05:35Z
last_api_response_total_tokens=241526
all_history_items_model_visible_bytes=781135
estimated_tokens_of_items_added_since_last_successful_api_response=4271
failing_compaction_request_model_visible_bytes=797454
model_context_window_tokens=258400

2026-05-31T20:33:31Z
last_api_response_total_tokens=241526
all_history_items_model_visible_bytes=781135
estimated_tokens_of_items_added_since_last_successful_api_response=4271
failing_compaction_request_model_visible_bytes=797454
model_context_window_tokens=258400

Local checks

Fresh bundled codex doctor --summary result:

17 ok · 1 idle · 1 notes · 0 warn · 0 fail ok

Connectivity checks:

Responses WebSocket handshake: HTTP 101 Switching Protocols
Proxy environment variables: none
WinHTTP proxy: direct access
DNS resolution for chatgpt.com: OK
TCP chatgpt.com:443: OK
Unauthenticated POST /backend-api/codex/responses/compact: HTTP 401

The endpoint is reachable from this machine. Ordinary turns and tool execution continue to work; the failures are specific to the remote compaction path near the context limit.

Related reports

• Primary open tracker: https://github.com/openai/codex/issues/17392
• Related Windows Codex Desktop report: https://github.com/openai/codex/issues/24544
• OpenAI status incident resolved on May 28, 2026: https://status.openai.com/incidents/01KSN9ATSF1WCJ5ZTQSR1H9CC7

Expected behavior

Remote compaction should complete reliably. If it fails, Codex should preserve thread usability and provide an automatic fallback or a clear recovery path instead of repeatedly breaking the active thread.

Privacy note

This report intentionally omits account identifiers, thread IDs, session IDs, local filesystem paths, repository details, raw logs, and transcript content.

I have a small behavior-preserving patch prepared for the failure-receipt side of this cluster. It does not attempt to fix the underlying /responses/compact stream disconnect, but it makes the user-visible/task error receipt clearer when remote compaction fails before replacement history is installed.

Branch:

https://github.com/carltonawong/codex/tree/carlton/remote-compaction-failure-receipt

Relevant scope:

• legacy remote compaction: codex-rs/core/src/compact_remote.rs
• remote compaction v2: codex-rs/core/src/compact_remote_v2.rs
• regression coverage: codex-rs/core/tests/suite/compact_remote.rs

The main invariant the patch adds to the error receipt is:

remote compaction failed, replacement history was not installed, and existing thread history was preserved

Why I think this is useful for this issue: several reports here mix two separate concerns — the actual remote compact failure, and whether the thread/history was lost or corrupted afterward. This patch keeps those concerns separate in the receipt so users and maintainers can tell that the compact attempt failed without implying that local history replacement happened.

Local validation on the branch:

cargo fmt --check
git diff --check
cargo test -p codex-core --test all compact_remote -- --nocapture
  38 passed; 0 failed; 1 ignored
cargo test -p codex-core --test all compact_remote -- --include-ignored --nocapture
  39 passed; 0 failed; 0 ignored

I tried to open this as a PR, but the compare page reports that openai/codex currently limits opening PRs to collaborators. If maintainers want this split out differently, I can adjust the branch to match the preferred shape.

Looked into this. The /responses/compact call fails at the transport layer (error sending request for url ... → CodexErr::Stream), and run_auto_compact then aborts the turn. Since history is still over the limit, the next turn retries the same failing compaction — so the session stays stuck.

Suggestion: when remote compaction fails with a retryable/transport error, fall back to the existing local summarization compaction (run_inline_auto_compact_task, normal /responses path) instead of aborting. It self-heals on a full window, so the session keeps going.

Reference patch (both v1/v2 paths, with tests): https://github.com/xiaocang/codex/pull/1

when will this bug being fixed? I see 2 other similar issues are closed as duplicate but this annoying bug is never being fixed...

I’m seeing the same failure repeatedly in Codex Desktop, and it is now blocking completion of long-running projects because automatic compaction does not recover.

Environment:

• Codex app: 26.602.40724 (CFBundleVersion 3593)
• Bundled/session CLI version in local JSONL: 0.137.0-alpha.4
• Platform: macOS 26.5.1 (25F80), arm64, Apple Silicon
• Model in the affected turn contexts: gpt-5.5
• Origin/source in session metadata: Codex Desktop, vscode

Visible error shown in the Codex UI in all three affected conversations:

Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

Affected local thread IDs:

codex://threads/019e9b96-b829-7562-96bc-802310766d53
codex://threads/019e9983-6d9f-7ca2-955f-0333080f5fdc
codex://threads/019e9739-ca62-7512-8fe5-aab13b3d4f11

Observed pattern from the local session JSONL/logs:

| Thread | Started | Task shape | Local evidence |
|---|---:|---|---|
| 019e9b96-b829-7562-96bc-802310766d53 | 2026-06-06T06:20:06Z | Long Penman/FSA workbook rebuild with subagents, web/data gathering, and checkpointing | session reached ~100,453 tracked tokens in ~329s; last assistant progress message was mid-pipeline rewrite; compaction failed in UI before the project could finish |
| 019e9983-6d9f-7ca2-955f-0333080f5fdc | 2026-06-05T20:39:47Z | Long IHG Penman/FSA workbook/report export and visual QA | session reached ~578,944 tracked tokens; on resume the desktop log reports maybe_resume_success ... latestTurnStatus=interrupted markedStreaming=true; user had to interrupt/start over after the compact failure |
| 019e9739-ca62-7512-8fe5-aab13b3d4f11 | 2026-06-05T10:00:07Z | TAG/LEG Penman/FSA workflow, then continuation to inspect a Word framework including embedded images | first task completed; continuation later reached ~227,857 tracked tokens, then UI showed the same remote compact error and the JSONL records repeated turn_aborted / interrupted states |

Two details that may help debugging:

1. The exact compact error is visible in the UI, but in these local JSONL files I do not see a corresponding structured event_msg with the compact error. The JSONL mostly shows token growth and then turn_aborted: interrupted or a resumed turn staying interrupted/markedStreaming in desktop logs. If the compact task is failing outside the normal event stream, that may make recovery/debugging harder.
2. This is not tied to one workspace or one local command. It appeared across separate long financial-research/workbook threads. The common factor is high accumulated context plus automatic remote compaction.

Expected behavior: automatic compaction should either complete, retry, or fail gracefully while preserving a usable/resumable thread. It should not leave the user forced to restart a multi-hour project in a fresh conversation.

Actual behavior: the thread becomes effectively unusable after the remote compact request disconnects, and the user has to start over or manually reconstruct state from local artifacts/checkpoints.

I’m seeing the same failure repeatedly in Codex Desktop, and it is now blocking completion of long-running projects because automatic compaction does not recover. Environment: Codex app: 26.602.40724 (CFBundleVersion 3593) Bundled/session CLI version in local JSONL: 0.137.0-alpha.4 Platform: macOS 26.5.1 (25F80), arm64, Apple Silicon Model in the affected turn contexts: gpt-5.5 * Origin/source in session metadata: Codex Desktop, vscode Visible error shown in the Codex UI in all three affected conversations: `` Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact) ` Affected local thread IDs: ` codex://threads/019e9b96-b829-7562-96bc-802310766d53 codex://threads/019e9983-6d9f-7ca2-955f-0333080f5fdc codex://threads/019e9739-ca62-7512-8fe5-aab13b3d4f11 ` Observed pattern from the local session JSONL/logs: Thread Started Task shape Local evidence 019e9b96-b829-7562-96bc-802310766d53 2026-06-06T06:20:06Z Long Penman/FSA workbook rebuild with subagents, web/data gathering, and checkpointing session reached ~100,453 tracked tokens in ~329s; last assistant progress message was mid-pipeline rewrite; compaction failed in UI before the project could finish 019e9983-6d9f-7ca2-955f-0333080f5fdc 2026-06-05T20:39:47Z Long IHG Penman/FSA workbook/report export and visual QA session reached ~578,944 tracked tokens; on resume the desktop log reports maybe_resume_success ... latestTurnStatus=interrupted markedStreaming=true; user had to interrupt/start over after the compact failure 019e9739-ca62-7512-8fe5-aab13b3d4f11 2026-06-05T10:00:07Z TAG/LEG Penman/FSA workflow, then continuation to inspect a Word framework including embedded images first task completed; continuation later reached ~227,857 tracked tokens, then UI showed the same remote compact error and the JSONL records repeated turn_aborted / interrupted states Two details that may help debugging: 1. The exact compact error is visible in the UI, but in these local JSONL files I do not see a corresponding structured event_msg with the compact error. The JSONL mostly shows token growth and then turn_aborted: interrupted or a resumed turn staying interrupted/markedStreaming` in desktop logs. If the compact task is failing outside the normal event stream, that may make recovery/debugging harder. 2. This is not tied to one workspace or one local command. It appeared across separate long financial-research/workbook threads. The common factor is high accumulated context plus automatic remote compaction. Expected behavior: automatic compaction should either complete, retry, or fail gracefully while preserving a usable/resumable thread. It should not leave the user forced to restart a multi-hour project in a fresh conversation. Actual behavior: the thread becomes effectively unusable after the remote compact request disconnects, and the user has to start over or manually reconstruct state from local artifacts/checkpoints.

I forked codex to fix this problem using local compact
https://github.com/garyfpga/codex-compact-fix

if you don't mind the trouble give it a try
on my CLI I no longer have any problem
but still wish they will fix the remote compact or give back 1m context

I’m seeing the same failure repeatedly in Codex Desktop, and it is now blocking completion of long-running projects because automatic compaction does not recover. Environment: Codex app: 26.602.40724 (CFBundleVersion 3593) Bundled/session CLI version in local JSONL: 0.137.0-alpha.4 Platform: macOS 26.5.1 (25F80), arm64, Apple Silicon Model in the affected turn contexts: gpt-5.5 * Origin/source in session metadata: Codex Desktop, vscode Visible error shown in the Codex UI in all three affected conversations:

FYI, one of the problem is actually the timeout of the http request / the websocket request
it usually happens when using VPN
and sometimes the problem is complicated due to cloudflare challenge in the middle....

changing to local compact solve the problem but not a good solution

this is so disruptive to our flows ... I hope its fixed asap.

Thanks for reporting this problem. Until recently, Codex used a separate endpoint and server-side logic for compaction. We recently switched to a more robust approach where the compaction logic is moved locally using the same endpoint as normal turns. This eliminates "remote compaction" errors and increases the stability and reliability of compaction operations. If you see further problems with compaction, please use /feedback and open a new bug report.