Quay lại hướng dẫn
Khắc phục sự cố·1 tháng 10, 2026·Đọc 7 phút

NanoClaw Codex timeout: vì sao một lượt bị đình trệ phải chờ mười phút, đã tái hiện

Một Responses WebSocket bị đình trệ, một lần thử lại đầu tiên bị ẩn và bộ hẹn giờ lượt chạy cố định mười phút: bot im lặng rồi thất bại, còn các tin nhắn gửi trong thời gian đó bị mất. Đã tái hiện với một endpoint thay thế, kèm cách khôi phục đã hiệu quả.

Được xem xét lần cuối vào .

"Turn timed out after 600000ms" trên nhà cung cấp Codex của NanoClaw có nghĩa là Responses WebSocket của Codex đã ngừng gửi sự kiện, và lỗi đầu tiên Codex báo cáo chỉ đến sau khi bộ hẹn giờ lượt mười phút cố định của NanoClaw đã kích hoạt. Codex chờ năm phút cho một luồng không hoạt động, thử lại âm thầm lần đầu và chỉ báo cáo lần thử lại thứ hai. Chúng tôi tái hiện vào ngày 1 tháng 10 năm 2026 với Codex 0.138.0 — phiên bản trong báo cáo lỗi — và 0.155.1, phiên bản NanoClaw hiện ghim, dựa trên một endpoint cục bộ chấp nhận kết nối rồi im lặng.

Đây là lần tái hiện phía sau issue #3338 của NanoClaw, issue vẫn đang mở và chưa có phản hồi của người bảo trì khi được kiểm tra. Để biết các lựa chọn nhà cung cấp, xem Chi phí API và nhà cung cấp của NanoClaw; nếu bot im lặng trên Telegram vì các lý do khác, xem NanoClaw Telegram không phản hồi.

Bạn thấy gì

Một tin nhắn gửi tới bot không nhận được câu trả lời — không lỗi, không phản hồi một phần — trong mười phút rồi mới có lỗi. Các tin nhắn gửi trong thời gian đó dường như biến mất. Trong log:

Sự cố trễ trông như thế nào trong log
# Codex, inside the agent container (from the issue; our 0.155.1 run printed the same reason)
stream error: idle timeout waiting for websocket
stream disconnected - retrying sampling request (1/5 ...)

# NanoClaw, ten minutes after the message
Error: Turn timed out after 600000ms

Lần tái hiện cho thấy điều gì

Số giây kể từ khi lượt bắt đầuCodex 0.138.0Codex 0.155.1 (bản NanoClaw ghim)
≈1–16Yêu cầu đầu tiên được gửi qua WebSocket; không có phản hồiYêu cầu khởi động, bị Codex đóng ở giây thứ 16; yêu cầu thật được gửi sau đó
≈300–316Yêu cầu đầu tiên hết thời gian chờ; Codex gửi lại yêu cầu của lượt — không có thông báoHết thời gian chờ không hoạt động; đã ghi nhận lần thử lại 1 — không có thông báo
600Bộ hẹn giờ của NanoClaw kết thúc lượt: "Turn timed out after 600000ms"
≈601–616Hết thời gian chờ không hoạt động; đã ghi nhận "retrying sampling request (1/5)" — vẫn không có thông báo nào (hoàn toàn không có trong 750 giây)Thông báo error đầu tiên: "Reconnecting... 2/5", "idle timeout waiting for websocket" — muộn 15 giây

Endpoint là một hệ thống thay thế chấp nhận WebSocket nhưng không gửi gì; client là tệp nhị phân app-server Codex thực, được điều khiển bằng cùng các lệnh gọi NanoClaw sử dụng và được đánh giá theo chính quy tắc của NanoClaw — bất kỳ thông báo lỗi nào hoặc một lượt hoàn tất sẽ kết thúc lượt, nếu không thì bộ hẹn giờ mười phút sẽ kết thúc.

Tại sao thời gian khớp tệ đến vậy

  • Codex chờ 300 giây cho sự kiện tiếp theo trên luồng Responses trước khi coi luồng là đã chết, và thử lại tối đa năm lần. Đây là các giá trị mặc định cho nhà cung cấp OpenAI tích hợp trong cả hai phiên bản.
  • Codex ẩn lần thử lại WebSocket đầu tiên. Mã thử lại của nó nói rõ điều đó trong một chú thích — "In release builds, hide the first websocket retry notification to reduce noisy transient reconnect messages" — vì vậy giao diện người dùng không nghe thấy gì cho đến lần thử lại thứ hai, khoảng mười phút sau.
  • NanoClaw cấp cho một lượt Codex đúng 600.000 ms và kết thúc lượt khi có bất kỳ thông báo lỗi nào. Hai cửa sổ không hoạt động cộng với quá trình khởi động của Codex dài hơn khoảng thời gian đó, vì vậy với các thiết lập mặc định, bộ hẹn giờ sẽ thắng.

Các tin nhắn gửi trong lúc im lặng bị mất

NanoClaw gửi tin nhắn tiếp theo đến turn/steer của Codex nếu nó đến trong lúc một lượt đang hoạt động. Trong lần chạy, Codex chấp nhận tin nhắn đó vào lượt bị đình trệ và không gửi gì mới lên upstream; sau khi hết thời gian chờ, tiếp tục thread cho thấy prompt ban đầu trong lịch sử nhưng không có tin nhắn được điều hướng. Điều đó khiến bot trông hoàn toàn bị kẹt: mọi thứ bạn nhập đều đi vào một lượt sẽ không bao giờ hoàn tất.

Thoát khỏi tình trạng này

Đã xác minh: sau khi hết thời gian chờ, tin nhắn tiếp theo tiếp tục cùng thread trên một app-server mới — đúng với cách NanoClaw hoạt động — và trong lần chạy, nó hoàn tất trong 0.16 giây ngay khi endpoint trả lời. Vì vậy: hãy chờ hết thời gian chờ, rồi gửi lại mọi thứ bạn đã nhập trong lúc im lặng. Nếu tin nhắn tiếp theo cũng bị đình trệ, kết nối upstream vẫn là vấn đề — hãy kiểm tra trạng thái của OpenAI và, nếu container kết nối tới OpenAI qua proxy, kiểm tra proxy đó có chuyển tiếp nâng cấp WebSocket hay không (pull request #2672 mô tả các proxy không làm được điều này; chưa kiểm thử ở đây).

Các tùy chọn rút ngắn thời gian chờ, đã đo nhưng chưa phát hành:

Thay đổiLỗi đầu tiên NanoClaw nhìn thấyĐiểm cần lưu ý
Codex qua HTTP/SSE thay vì WebSockets — PR #3851, đang mở, chưa hợp nhất300 s: "Reconnecting... 1/5"Thông báo nói Codex sẽ thử lại, và nó đã thử, nhưng NanoClaw kết thúc lượt khi nhận thông báo đó — thất bại sau năm phút thay vì mười phút
Codex stream_idle_timeout_ms = 60.000 trên WebSockets136 giâyNanoClaw tự ghi config.toml của Codex, vì vậy đây là thay đổi mã, không phải một thiết lập bạn có thể thêm vào

Cả hai vẫn kết thúc lượt như một lỗi. Điều các phép đo chỉ ra nằm ở phía NanoClaw — coi lỗi đang thử lại là tiến trình thay vì kết thúc, hoặc đo ngân sách lượt từ sự kiện thực cuối cùng — nhưng đó là suy luận từ các lần chạy này, không phải bản sửa lỗi đã được người bảo trì xác nhận.

Câu hỏi thường gặp

Tại sao agent Codex của NanoClaw im lặng trong mười phút rồi hết thời gian chờ?

Vì dấu hiệu sự cố đầu tiên mà Codex sẵn sàng báo cáo xuất hiện sau khi NanoClaw đã bỏ cuộc. Khi Responses WebSocket ngừng gửi sự kiện, Codex chờ hết thời gian chờ không hoạt động 300 giây rồi thử lại — và trong các bản phát hành, nó cố ý ẩn lần thử lại WebSocket đầu tiên. Thông báo lỗi đầu tiên chỉ đến sau cửa sổ 300 giây thứ hai, vượt quá bộ hẹn giờ lượt cố định 600.000 ms của NanoClaw. Chúng tôi tái hiện vào ngày 1 tháng 10 năm 2026: Codex 0.138.0 không gửi thông báo nào trong 750 giây, còn 0.155.1 — phiên bản NanoClaw hiện ghim — gửi thông báo đầu tiên ở giây thứ 615.7; quy tắc của NanoClaw kết thúc lượt ở giây thứ 600.

Điều gì xảy ra với các tin nhắn tôi gửi trong lúc bot bị kẹt?

Chúng bị chuyển vào lượt đang bị kẹt và, trong lần chạy của chúng tôi, bị mất. NanoClaw định tuyến một tin nhắn tiếp theo đến trong lúc một lượt đang hoạt động vào turn/steer của Codex; Codex chấp nhận nó vào cùng lượt bị đình trệ, không gửi gì mới lên upstream, và sau khi hết thời gian chờ rồi tiếp tục, văn bản được điều hướng không có trong lịch sử của thread. Hãy gửi lại mọi thứ bạn đã nhập trong lúc im lặng sau khi bot trả lời lại.

Làm thế nào để khôi phục sau khi lượt NanoClaw Codex hết thời gian chờ?

Gửi tin nhắn tiếp theo. NanoClaw khởi động app-server mới và tiếp tục cùng thread; trong lần chạy của chúng tôi, lượt tiếp tục hoàn tất trong 0.16 giây ngay khi endpoint trả lời, với prompt ban đầu vẫn còn trong lịch sử. Nếu upstream vẫn bị đình trệ, lượt mới cũng sẽ đình trệ tương tự, vì vậy trước tiên hãy kiểm tra trạng thái của OpenAI hoặc đường truyền mạng — và gửi lại mọi tin nhắn tiếp theo đã bị nuốt mất.

Chuyển Codex sang HTTP thay vì WebSockets có khắc phục được không?

Nó rút ngắn thời gian im lặng, và chưa được hợp nhất. Pull request #3851 (đang mở, do người báo cáo issue gửi) thêm NANOCLAW_CODEX_TRANSPORT=http, định tuyến Codex qua HTTP/SSE. Trong lần chạy theo dạng đó, thông báo lỗi đầu tiên xuất hiện ở giây thứ 300 thay vì sau bộ hẹn giờ — nhưng nó mang willRetry true trong khi Codex đã gửi lại, và NanoClaw kết thúc lượt khi có bất kỳ thông báo lỗi nào, nên lượt sẽ thất bại sau năm phút thay vì khôi phục.

Đây có phải là lỗi hết thời gian chờ chung của Codex không?

Không. Bản thân Codex tiếp tục thử lại; sự im lặng mười phút xuất phát từ cách bộ hẹn giờ lượt của NanoClaw khớp với lần thử lại đầu tiên bị Codex ẩn. Trên 0.155.1, app-server báo "Reconnecting... 2/5" ở khoảng giây thứ 616 — một client có ngân sách lượt dài hơn sẽ nhìn thấy điều đó; NanoClaw thì không bao giờ thấy. Nhà cung cấp mặc định của NanoClaw là Claude Agent SDK, không liên quan trong trường hợp này.

Đã tái hiện vào ngày 1 tháng 10 năm 2026 với các tệp nhị phân app-server codex native từ npm (@openai/codex 0.138.0 và 0.155.1, darwin-arm64), điều khiển qua stdio với các tham số initialize, thread/start, turn/start và turn/steer trong nhánh providers của NanoClaw (commit 3959d1f055), dựa trên một hệ thống thay thế Responses cục bộ qua WebSocket và HTTP/SSE. Các giá trị mặc định của Codex và lần thử lại đầu tiên bị ẩn được đọc từ codex-rs tại các tag rust-v0.138.0 và rust-v0.155.1. Chưa chạy: orchestrator và container của NanoClaw, OneCLI, Telegram hoặc endpoint thực của OpenAI — hệ thống thay thế tái tạo một luồng im lặng, không phải nguyên nhân khiến endpoint OpenAI im lặng. Trạng thái issue và pull request được đọc trong cùng ngày.