[CLI 0.149.0] /feedback consistently fails after ~5s on Sentry DNS resolution in network-restricted tmux session

What version of Codex is running?

codex-cli 0.149.0

Install details:

• Installed with pnpm (pnpm 11.17.0, Node.js v18.19.1)
• Linux x64 musl binary
• Custom CODEX_HOME under the user's home directory
• ChatGPT-authenticated; the exact subscription tier is not surfaced by codex doctor or the CLI
• Active model: gpt-5.6-sol

What platform is your computer?

Linux 6.17.0-35-generic x86_64 x86_64

• Ubuntu 24.04.3 LTS (Noble)
• AMD Ryzen 7 7700 8-Core Processor (8 cores / 16 threads)
• 61 GiB RAM

What terminal and multiplexer are you using?

Codex is being accessed over SSH from Ghostty 1.3.1, inside tmux 3.4:

• Shell: zsh
• TERM=tmux-256color
• tmux client terminal: xterm-ghostty
• tmux client size: 188x46

codex doctor --json

I ran the doctor outside the tool sandbox so that it measured host connectivity. Relevant redacted results:

{
  "overallStatus": "warning",
  "codexVersion": "0.149.0",
  "network": {
    "provider_reachability": {
      "status": "ok",
      "summary": "Provider endpoint reachable"
    },
    "websocket_reachability": {
      "status": "ok",
      "summary": "WebSocket handshake succeeded (HTTP 101)"
    }
  },
  "sandbox": {
    "helpers": {
      "details": {
        "filesystem sandbox": "restricted",
        "network sandbox": "restricted"
      }
    }
  },
  "updates": {
    "status": {
      "status": "warning",
      "details": {
        "latest version probe": "curl: (28) Resolving timed out after 5001 milliseconds"
      }
    }
  },
  "terminal": {
    "env": {
      "details": {
        "terminal": "Ghostty",
        "terminal version": "1.3.1",
        "multiplexer": "tmux 3.4"
      }
    }
  }
}

The full redacted doctor output is available if useful.

What is the actual behavior?

Submitting /feedback consistently fails after approximately five seconds. Four consecutive attempts produced the same DNS/connect error:

feedback upload failed ... error=failed to upload feedback to Sentry: error sending request for url (https://o33249.ingest.us.sentry.io/api/4510195390611458/envelope/): client error (Connect): dns error: failed to lookup address information: Try again

The four observed attempts in the Codex logs were:

| UTC timestamp | Classification | Include logs | Attachments | Payload | Failure time |
|---|---|---:|---:|---:|---:|
| 2026-08-22 07:56:52 | other | true | 10 | 49,236,551 bytes | 5.053 s |
| 2026-08-22 08:00:02 | other | true | 10 | 49,640,845 bytes | 5.053 s |
| 2026-08-22 08:02:14 | other | true | 10 | 49,847,232 bytes | 5.052 s |
| 2026-08-22 08:03:35 | good_result | true | 10 | 50,105,572 bytes | 5.053 s |

The error occurs before any payload upload, during DNS resolution. The 49–50 MB payload size may be independently relevant, but does not appear to cause this specific failure.

Steps to reproduce

1. Start Codex CLI 0.149.0 over SSH on this Ubuntu machine, inside tmux 3.4.
2. Run /feedback in an active Codex session.
3. Choose a classification and leave log inclusion enabled.
4. Submit the feedback.
5. Wait about five seconds.
6. Observe the failure notification and the codex_feedback warning in the logs.
7. Repeat; every attempt has failed identically.

What is the expected behavior?

Feedback should upload successfully from a working Codex session. The feedback transport should either:

• operate from a host-side networking context and tolerate ordinary cold DNS latency, or
• retry resolution with a sufficiently long timeout and return an actionable error if it ultimately fails.

Additional context and diagnosis

The host network itself can resolve and reach the Sentry endpoint:

• First, uncached request: DNS 5.025 s, TCP connect 5.034 s, total 5.160 s; server returned HTTP 404 for an intentionally empty GET.
• Immediate second request: DNS 0.006 s, TCP connect 0.012 s, total 0.131 s.
• The Sentry hostname resolves to both IPv4 and IPv6 on the host.
• Codex provider HTTP and WebSocket checks succeed outside the tool sandbox.
• The system uses systemd-resolved; no HTTP proxy is configured.

The 5.025-second cold host lookup is nearly identical to every feedback failure at 5.052–5.053 seconds. My current hypothesis is that the uploader has a fixed five-second connect/DNS deadline that races with an uncached resolver lookup. A second possibility is that the uploader is inheriting the active network-restricted tool context (CODEX_SANDBOX_NETWORK_DISABLED=1) even though feedback is a Codex control-plane action. Both are inferences from the timing and environment, not confirmed root causes.

Other potentially relevant observations:

• Running codex doctor inside the tool sandbox predictably reports DNS operations as not permitted; outside it, provider and WebSocket reachability pass.
• Even outside the sandbox, the doctor's cached update probe reports Resolving timed out after 5001 milliseconds, matching the suspected deadline.
• Startup in this managed environment emits: WARNING: proceeding, even though we could not create PATH aliases: Read-only file system (os error 30). This may be unrelated.
• Active Codex thread/session ID: 01a027bf-db14-7092-b89f-e9e8d412e5b0.

Related but distinct: #16304 reports desktop feedback failures associated with Sentry HTTP 429 responses. This report is for the Linux CLI and fails earlier at DNS/connect resolution.

No feedback attachments or sensitive log contents are included in this report.