Bản phát hành gây hỗn loạn: Khi OpenClaw v2026.4.5 "phá hỏng" mọi thứ

Một số bản phát hành mang đến tính năng mới, một số khác sửa lỗi, nhưng OpenClaw v2026.4.5 lại mang đến sự hỗn loạn. Bản cập nhật này đã gây ra hàng loạt lỗi nghiêm trọng trên mọi nền tảng chính, biến các hệ thống ổn định thành những cỗ máy tiêu tốn tài nguyên và liên tục sập đổ chỉ trong vài giờ sau khi nâng cấp.

Hãy cùng nhìn vào những gì đã xảy ra, vì các chế độ lỗi ở đây là những ví dụ kinh điển về cách sự phức tạp trong phần mềm bị cộng hưởng.

Báo cáo thiệt hại

Trong vòng 24 giờ sau khi OpenClaw v2026.4.5 ra mắt, người dùng đã báo cáo lỗi trên macOS, Windows và Linux. Dưới đây là những điểm nhấn đáng sợ nhất.

macOS: 87 tiến trình và 888% CPU

Vấn đề #62051 là loại báo cáo lỗi khiến bất kỳ kỹ sư nào cũng phải "rùng mình". Một người dùng Mac Mini nâng cấp từ v2026.4.2 và nhìn thấy hệ thống của mình tạo ra hơn 87 tiến trình worker, mỗi tiến trình đều tự tải lại tất cả các plugin một cách độc lập:

[plugins] BlockRun provider registered (55+ models via x402)
[plugins] Registered 1 partner tool(s): blockrun_x_users_lookup
[plugins] Not in gateway mode — proxy will start when gateway runs

Thông điệp đó lặp lại cho từng tiến trình con. Kết quả là:

• 103 tiến trình openclaw tổng cộng (so với ~8 ở phiên bản trước)
• 888% CPU sử dụng trên tất cả các nhân
• Load average đạt 17.77 trên máy có 8-10 nhân
• Thời gian phản hồi API tăng từ 10ms lên hơn 2 phút

Nguyên nhân gốc rễ: quá trình đăng ký plugin vốn chỉ nên diễn ra một lần trong tiến trình gateway lại bị chạy ở mọi tiến trình worker con. Mỗi tiến trình đều tải tất cả các nhà cung cấp, khởi tạo trình theo dõi hệ thống tệp và tranh giành thời gian CPU.

Windows: Tràn bộ nhớ Stack ngay khi khởi động

Vấn đề #62055 tấn công người dùng Windows với một chế độ lỗi hoàn toàn khác. CLI thậm chí không thể khởi động được:

RangeError: Maximum call stack size exceeded
    at evaluateSync (node:internal/modules/esm/module_job:458:26)

Đồ thị mô-đun ESM đã phát triển đáng kể giữa các bản phát hành. Trên Linux và macOS, stack mặc định của V8 (~8 MB) xử lý tốt vấn đề này. Tuy nhiên, trên Windows, stack mặc định chỉ khoảng ~1 MB không thể chịu đựng nổi. Những người dùng cố gắng vượt qua lỗi stack bằng cờ --stack-size sau đó lại tiếp tục gặp lỗi thiếu bộ nhớ heap (OOM) ở mức 4 GB.

Cùng một mã nguồn, cùng một phiên bản, nhưng lại sập đổ hoàn toàn khác nhau — bởi vì quy trình phát hành không kiểm thử đối với các thiết lập mặc định cụ thể của V8 trên từng nền tảng.

Linux: Công cụ hiển thị dạng văn bản thô

Vấn đề #62089 tinh tế hơn nhưng có thể nói là tồi tệ hơn. Các cuộc gọi công cụ (tool calls) ngừng hiển thị đúng định dạng trên mọi kênh UI — control-ui, Telegram, TUI. Thay vì đầu ra được định dạng đẹp mắt, người dùng chỉ thấy các khối [TOOL_CALL] dạng văn bản thô.

Các công cụ vẫn thực thi bình thường. Kết quả vẫn đúng. Nhưng lớp trình bày bị hỏng, khiến agent trông giống như đang phun ra dữ liệu của trình phân tích cú pháp. Đối với người dùng không chuyên, agent đột nhiên trông có vẻ bị hỏng dù thực tế thì không.

Hiệu ứng cộng hưởng

Một người dùng (#62095) đã ghi lại trải nghiệm đầy đủ: khởi động lại gateway 10 lần trong 8 giờ. Cài đặt Mac Studio M3 Ultra vốn ổn định của họ đã gặp phải tất cả các vấn đề cùng một lúc:

1. doctor --fix không thực sự sửa các cảnh báo mà nó báo cáo
2. Timeout thông báo subagent mặc định là 120s, chặn gateway lên tới 8 phút cho mỗi lần thất bại
3. Các kiểm tra bảo mật mới làm hỏng cài đặt LAN hiện có mà không có hướng dẫn di chuyển
4. Slack health-monitor kết nối lại mỗi 35 phút trong một vòng lặp vô tận
5. Gateway đạt mức 1.5GB RAM với 379 tệp phiên tích lũy

Mỗi vấn đề một mình thì có thể sống sót. Nhưng khi cộng hưởng lại, chúng khiến hệ thống trở nên vô dụng.

Tại sao chuyện này xảy ra

Điều này không phải là duy nhất đối với OpenClaw. Bất kỳ dự án phát triển nhanh nào với những đặc điểm này đều dễ bị tổn thương:

1. Ranh giới cô lập plugin thay đổi âm thầm. Việc thay đổi tiến trình worker có vẻ vô hại trong diff code — có thể là một refactor di chuyển khởi động lên sớm hơn, hoặc một đường dẫn khởi động ngừng kiểm tra xem nó có ở chế độ gateway hay không. Nhưng nó biến một thao tác tải đơn thành thao tác tải N lần, trong đó N là số lượng worker.

2. Giới hạn cụ thể của nền tảng không có trong CI. Đồ thị mô-đun phát triển dần dần qua nhiều PR. Không có thay đổi riêng lẻ nào là vấn đề. Nhưng hiệu ứng tích lũy đã vượt qua ngưỡng stack của Windows. Nếu không có runner CI Windows với các giới hạn bộ nhớ, điều này sẽ vô hình cho đến ngày phát hành.

3. Các giá trị mặc định là "gánh nặng cấu trúc". Timeout thông báo 120 giây có lẽ ổn khi subagent hiếm khi gặp. Nhưng khi mô hình sử dụng phát triển — nhiều agent hơn, nhiều công việc đồng thời hơn — giá trị mặc định trở thành vectơ từ chối dịch vụ (DoS) đối với chính gateway.

4. Các lỗi hiển thị là kẻ sát thủ thầm lặng. Lỗi hiển thị công cụ không ảnh hưởng đến chức năng nào cả. Nhưng nó phá hủy trải nghiệm người dùng. Những lỗi này thường lọt qua kiểm thử vì các bài test tự động chỉ kiểm tra "công cụ có chạy không?" chứ không kiểm tra "kết quả có hiển thị đúng không?".

Mô hình sâu xa hơn

Điều làm cho v2026.4.5 thú vị không phải là bất kỳ lỗi đơn lẻ nào — mà là sự đồng thời. Năm chế độ lỗi khác nhau, trên ba nền tảng, tất cả trong một bản phát hành. Điều này thường có nghĩa là một trong hai điều:

1. Một thay đổi cấu trúc lớn (như refactor tải plugin) đã gây ra hiệu ứng dây chuyền không được truy xuất đầy đủ
2. Nhiều thay đổi rủi ro được gộp vào cùng một cửa sổ phát hành mà không có thời gian "ngâm" (soak time) đủ lâu

Giải pháp hầu như không bao giờ là "kiểm thử nhiều hơn" một cách trừu tượng. Nó phải cụ thể hơn:

• Canary releases (phát hành kiểu chim ưng) tiếp xúc thay đổi với một tập hợp con người dùng trước
• CI đa nền tảng để bắt các lỗi cụ thể của Windows trước khi chúng được phát hành
• Kiểm thử ngân sách tài nguyên sẽ thất bại khi số lượng tiến trình hoặc bộ nhớ vượt quá giới hạn dự kiến
• Tài liệu rollback để người dùng biết chính xác cách quay trở lại phiên bản ổn định cuối cùng

Dành cho những người xây dựng Agent

Nếu bạn đang xây dựng dựa trên một framework agent phát triển nhanh:

1. Cố định phiên bản (Pin your versions). Đừng tự động nâng cấp lên latest. Hãy đợi 48-72 giờ sau khi phát hành và kiểm tra trình theo dõi vấn đề (issue tracker).
2. Giám sát tài nguyên của bạn. Số lượng tiến trình, bộ nhớ, CPU — đây là hệ thống cảnh báo sớm của bạn. Một sự tăng vọt đột ngột sau khi nâng cấp có nghĩa là một thứ gì đó đã thay đổi mà changelog không đề cập đến.
3. Lưu giữ binary của phiên bản trước. Khả năng rollback trong 30 second có giá trị hơn bất kỳ lượng kiểm thử nào.
4. Kiểm thử nền tảng cụ thể của bạn. "Works on my machine" (Chạy trên máy của tôi thì ổn) đặc biệt nguy hiểm khi mã nguồn nhắm đến Linux, macOS và Windows đồng thời.

v2026.4.5 sẽ được vá lỗi. Các lỗi riêng lẻ sẽ được sửa. Nhưng mô hình — của các lỗi hồi quy (regressions) cộng hưởng lọt qua các cổng phát hành — rất đáng để nghiên cứu. Vì lần sau nó xảy ra, các triệu chứng sẽ khác nhau, nhưng hình thức thất bại sẽ y hệt như vậy.