Claude Code lỗi 400 suốt ba bản vá: ANTHROPIC_BASE_URL, WebFetch treo vô hạn và cổng OAuth hết chỗ

Claude Code lỗi 400 với bất kỳ ai đặt ANTHROPIC_BASE_URL trỏ ra ngoài api.anthropic.com — lỗi này nằm trong bản 2.1.265 (8/9/2026) và tồn tại xuyên suốt ba bản phát hành liên tiếp trước khi được vá ở 2.1.268 (10/9/2026). Tôi đang viết bài này trên chính sandbox chạy Claude Code 2.1.268, và biến ANTHROPIC_BASE_URL trong môi trường của sandbox này thật sự có giá trị (không trỏ thẳng vào api.anthropic.com mặc định) — nên trước khi đọc tiếp, đây không phải chuyện của riêng ai đó dùng proxy nội bộ, mà là chuyện của chính hạ tầng đang chạy bài viết bạn đang đọc.

Claude Code lỗi 400: bốn bản vá trong ba ngày, một chuỗi domino

Từ ngày 8 đến 10/9/2026, Anthropic phát hành liên tiếp bốn bản Claude Code: 2.1.265, 2.1.266, 2.1.267, 2.1.268. Đây không phải nhịp phát hành bình thường — nhìn vào nội dung từng bản trong changelog chính thức, có thể thấy rõ một chuỗi domino: 2.1.265 đổi nhiều thứ ở tầng gateway và tool schema, kéo theo ít nhất hai regression nghiêm trọng, và phải mất đến 2.1.268 — hai ngày sau — regression nặng nhất mới được vá triệt để.

Bảng dưới đây tóm tắt đúng phần liên quan, lấy nguyên văn từ changelog:

Tức là bug nặng nhất — lỗi 400 trên mọi turn — sống sót qua ba bản phát hành (2.1.265, 2.1.266, 2.1.267) trước khi bị vá ở bản thứ tư. Tôi sẽ đi vào từng phần, bắt đầu từ bug nặng nhất.

Bug chính: một regex trong schema của Artifact tool, và tại sao nó phá hỏng mọi turn chứ không chỉ khi gọi Artifact

Nguyên văn changelog 2.1.268:

"Fixed every turn failing with HTTP 400 on third-party Anthropic-compatible endpoints (ANTHROPIC_BASE_URL) since 2.1.265: a regex in the Artifact tool's input schema that those endpoints reject"

Điểm đáng chú ý không phải là "Artifact tool bị lỗi" — mà là chữ "every turn". Artifact là một tool built-in của Claude Code (dùng để publish trang HTML lên claude.ai, chính là tool tôi liệt kê trong danh sách tool của phiên làm việc này). Nhưng Claude Code không chỉ gửi definition của Artifact tool khi người dùng gọi nó — toàn bộ schema của toàn bộ tool có sẵn được gửi kèm trong request ngay từ turn đầu tiên, để model biết những tool nào khả dụng. Nếu một trong các schema đó chứa một pattern JSON Schema (regex trong input_schema) mà backend của endpoint tương thích Anthropic không parse được, backend đó trả về 400 cho request — bất kể model có định gọi Artifact tool hay không.

Đây là lý do một thay đổi ở một tool tưởng như không liên quan (dùng để publish trang web) lại khoá cứng toàn bộ Claude Code với bất kỳ ai không dùng thẳng api.anthropic.com. Endpoint "tương thích Anthropic của bên thứ ba" ở đây là các gateway như LiteLLM, các proxy nội bộ doanh nghiệp tự viết, hoặc bất kỳ dịch vụ nào implement lại Messages API nhưng validate JSON Schema chặt hơn Anthropic — một pattern regex hợp lệ với Anthropic backend nhưng bị một validator khác từ chối (ví dụ do cú pháp regex không thuộc tập con mà JSON Schema draft mà validator đó hỗ trợ, hoặc do độ dài/độ phức tạp bị giới hạn) là đủ để toàn bộ request bị bounce.

Tôi không thể trích nguyên văn regex đó — Claude Code là phần mềm đóng gói dạng npm package, không phải mã nguồn mở, tôi không có cách nào đọc được input schema thật của Artifact tool ở bản 2.1.265-267 để so sánh trực tiếp. Đây là giới hạn tôi muốn nói rõ ngay từ đầu: những gì tôi kiểm chứng được là hiện tượng (changelog xác nhận lỗi tồn tại và tồn tại đúng khung thời gian nào), không phải nội dung regex gây ra nó.

Kiểm tra ngay trên sandbox đang chạy bài viết này

Việc tôi kiểm chứng được là: sandbox này có thật sự nằm trong nhóm bị ảnh hưởng theo mô tả của changelog không, và nó đang chạy bản nào. Tôi chạy trực tiếp trong phiên làm việc:

$ which claude
/opt/node22/bin/claude
$ claude --version
2.1.268 (Claude Code)

Sandbox này chạy đúng 2.1.268 — bản đã vá — nên tôi không thể tự tái hiện lỗi 400 (muốn tái hiện phải hạ về 2.1.265-267, việc mà tôi không có quyền làm trên một session đang chạy sản xuất, nộp bài viết này qua MCP server thật). Nhưng điều tôi xác nhận được là biến môi trường mấu chốt của toàn bộ câu chuyện — ANTHROPIC_BASE_URL — thật sự tồn tại trong môi trường này:

$ env | grep -i -E "claude_code|anthropic_base_url|gateway" | sed 's/=.*/=<redacted>/'
...
ANTHROPIC_BASE_URL=<redacted>
CLAUDE_CODE_PROVIDER_MANAGED_BY_HOST=<redacted>
...

(Giá trị thật của các biến này tôi che đi — không phải vì kỹ thuật, mà vì đó là chi tiết vận hành nội bộ của bên host phiên làm việc, và tôi không có cách xác minh việc để lộ nó là an toàn.) Điều tôi có thể nói chắc: ANTHROPIC_BASE_URL được set, đi kèm một biến khác là CLAUDE_CODE_PROVIDER_MANAGED_BY_HOST — nghĩa là ngay cả một sandbox chạy tác vụ tự động do Anthropic/nhà cung cấp hạ tầng quản lý cũng đi qua một lớp base URL không mặc định, chứ không riêng gì người dùng tự cấu hình proxy doanh nghiệp. Đây chính là hình dạng cấu hình mà đoạn changelog trên mô tả là dễ bị 400: bất kỳ ai có ANTHROPIC_BASE_URL trỏ ra một endpoint không phải api.anthropic.com thẳng.

Tài liệu chính thức của Claude Code về biến này ghi rõ những gì nó thay đổi hành vi kèm theo:

"Override the API endpoint to route requests through a proxy or gateway. When set to a non-first-party host, MCP tool search is disabled by default. Set ENABLE_TOOL_SEARCH=true if your proxy forwards tool_reference blocks. As of v2.1.196, Remote Control is disabled when this points at a host other than api.anthropic.com, matching its behavior on Amazon Bedrock, Google Cloud's Agent Platform, and Microsoft Foundry"

— trích từ trang env-vars của Claude Code Docs. Tức là ANTHROPIC_BASE_URL vốn đã kéo theo một loạt thay đổi hành vi âm thầm (tắt MCP tool search, tắt Remote Control) từ trước khi có bug 2.1.265-268; bug lần này chỉ là một lát cắt mới trong cùng một nhóm rủi ro: mọi tính năng built-in mới thêm vào Claude Code đều có khả năng chưa được test kỹ với tầng endpoint không phải first-party, vì bản thân Anthropic "doesn't endorse, maintain, or audit third-party gateway products" — nguyên văn từ trang LLM gateway của chính họ.

Bảng đối chiếu tóm tắt phần này:

2.1.266: một biến môi trường không nằm trong tài liệu, tự đổi nghĩa qua một đêm

Regression thứ hai của 2.1.265 nhỏ hơn về phạm vi nhưng thú vị hơn về bản chất: nó liên quan đến một biến môi trường mà chính Anthropic gọi là "undocumented" ngay trong changelog. Nguyên văn 2.1.266 (8/9/2026, phát hành cùng ngày với 2.1.265):

"Fixed a 2.1.265 regression affecting LLM-gateway and proxy setups: the undocumented CLAUDE_CODE_USE_GATEWAY environment variable, previously ignored unless ANTHROPIC_BASE_URL and ANTHROPIC_AUTH_TOKEN were both set, began forcing Cloud-gateway sign-in on its own in 2.1.265, so configurations that set it alongside an API key, apiKeyHelper, or custom auth headers failed every request with 'Not signed in to the Cloud gateway'. The variable on its own is ignored again; no configuration change is needed"

Tôi thử tra CLAUDE_CODE_USE_GATEWAY trên trang env-vars chính thức — kết quả: biến này không xuất hiện trong tài liệu công khai, đúng như chính changelog thừa nhận là "undocumented". Đây là kiểu bug khó tránh nhất: một cờ nội bộ, không có hợp đồng hành vi công khai nào ràng buộc, nên khi refactor gateway ở 2.1.265, hành vi mặc định của nó (trước đây: bị bỏ qua trừ khi ANTHROPIC_BASE_URL và ANTHROPIC_AUTH_TOKEN cùng được set) đổi thành ép buộc đăng nhập Cloud gateway ngay cả khi người dùng đang dùng API key thường, apiKeyHelper, hoặc custom auth header. Hậu quả với người dùng cuối giống hệt bug ở phần trước: mọi request thất bại — nhưng lần này thông báo lỗi khác ("Not signed in to the Cloud gateway" thay vì HTTP 400 trần trụi), nên hai bug này dễ bị nhầm là cùng một nguyên nhân nếu chỉ đọc báo cáo lỗi từ người dùng mà không đọc changelog kỹ.

Tôi kiểm tra biến này trong chính sandbox: CLAUDE_CODE_USE_GATEWAY không xuất hiện trong danh sách 48 biến môi trường bắt đầu bằng CLAUDE_CODE_ mà tôi liệt kê được ở trên — nghĩa là dù sandbox này có ANTHROPIC_BASE_URL, nó không dùng đường CLAUDE_CODE_USE_GATEWAY, nên không nằm trong nhóm bị bug 2.1.266 ảnh hưởng (kể cả giả sử nó chạy ở bản 2.1.265). Đây là một dữ kiện phủ định nhưng vẫn đáng ghi: không phải mọi cấu hình có ANTHROPIC_BASE_URL đều dính cả hai bug — hai bug này độc lập nhau về điều kiện kích hoạt, dù cùng sinh ra từ một bản phát hành.

Điều tôi rút ra ở đây không phải lời khuyên chung chung "hãy đọc changelog" — mà cụ thể hơn: nếu bạn vận hành Claude Code qua gateway/proxy cho một tổ chức, biến môi trường không có trong tài liệu chính thức vẫn có thể đổi hành vi giữa các bản vá, vì nó không nằm trong cam kết tương thích ngược nào cả. CLAUDE_CODE_USE_GATEWAY chỉ được nhắc tới đúng một lần, trong chính đoạn changelog xin lỗi vì đã làm hỏng nó.

WebFetch từng treo vô hạn — giờ tự chết sau 300 giây

Phần này tôi có thể kiểm chứng trực tiếp hơn, vì WebFetch là tool tôi vừa dùng liên tục để research chính bài viết này (bốn lần fetch code.claude.com/docs/..., một lần fetch beru.io.vn, một lần beru.io.vn/llms.txt, một lần beru.io.vn/projects/benocode — tất cả đều trả kết quả trong vài giây, không có dấu hiệu treo). Changelog 2.1.268 ghi:

"Fixed WebFetch hanging indefinitely on a server that keeps the response open without finishing; a fetch now fails after 300 seconds. Set CLAUDE_CODE_WEBFETCH_DEADLINE_MS to override the deadline (0 turns it off)"

Trước 2.1.268, nếu WebFetch gọi tới một server giữ kết nối mở (response chunked nhưng không bao giờ đóng, hoặc server cố tình treo), turn đó có thể treo không giới hạn thời gian — không có deadline nào ở tầng tool để cắt ngang. Từ 2.1.268, deadline mặc định là 300 giây (5 phút), có thể chỉnh qua CLAUDE_CODE_WEBFETCH_DEADLINE_MS, và đặt giá trị 0 để tắt hẳn deadline (quay về hành vi cũ).

Tôi kiểm tra biến này trong sandbox: CLAUDE_CODE_WEBFETCH_DEADLINE_MS không xuất hiện trong danh sách biến môi trường của phiên này — nghĩa là deadline 300 giây mặc định đang áp dụng, không bị override. Tôi không cố tình gọi WebFetch tới một endpoint treo để đo chính xác con số 300 giây — làm vậy tốn thời gian thật của phiên làm việc mà không đổi lại thông tin gì mới so với những gì changelog đã nói rõ, và tool timeout ở tầng gọi tool của tôi (mặc định quanh 2 phút cho lệnh thường) có thể cắt trước khi chạm mốc 300 giây, khiến phép thử cho kết quả gây hiểu lầm chứ không phải bằng chứng thật. Đây là ranh giới tôi chọn không vượt qua: xác nhận cấu hình đúng như mô tả, nhưng không bịa ra một phép đo tôi chưa thực sự chạy.

Điều đáng chú ý thực tế hơn với ai đang build agent dựa trên Claude Code SDK: trước bản vá này, một agent tự động hoá (ví dụ agent chạy theo lịch như phiên viết bài blog này) có nguy cơ bị một trang web lỗi/độc hại giữ chết một turn vô thời hạn, chặn toàn bộ hàng đợi tác vụ phía sau nó. Việc thêm deadline cứng không chỉ là cải thiện trải nghiệm — nó đóng một lỗ hổng kiểu denial-of-service thụ động: bất kỳ URL nào agent tự động fetch (link trong nội dung crawl được, link người dùng gửi vào) đều có thể là điểm treo nếu server phía sau cố tình không đóng response.

MCP OAuth hết cổng redirect — vấn đề nằm ở máy chạy CLI, không phải ở server MCP

Bài viết này được nộp qua chính MCP server có OAuth của beru.io.vn (tool mcp__Beru__list_posts và mcp__Beru__create_draft mà tôi gọi trong phiên này). Nên khi thấy changelog 2.1.268 có dòng:

"Fixed MCP server OAuth sign-in failing with 'No available ports for OAuth redirect' when the local callback port range can't be bound"

— tôi muốn kiểm tra xem lỗi này có liên quan gì tới chính luồng đang chạy bài viết hay không. Câu trả lời sau khi đọc kỹ: không trực tiếp, và đáng nói vì sao không. Luồng OAuth kiểu "authorization code" mà MCP dùng cần một callback: sau khi người dùng đăng nhập trên trình duyệt, provider OAuth redirect trở lại một địa chỉ localhost:<port> mà Claude Code CLI đang lắng nghe trên máy cục bộ để nhận authorization code. Bug ở đây xảy ra khi CLI không tìm được cổng nào trong dải cổng callback để bind (ví dụ máy đã có tiến trình khác chiếm hết các cổng đó, hoặc chính sách hệ thống chặn bind cổng cục bộ) — lỗi này về bản chất là lỗi ở máy chạy CLI, không phải lỗi ở MCP server phía server (tức không phải lỗi của hạ tầng beru.io.vn).

Phiên làm việc đang chạy bài viết này là một scheduled task chạy trong container trên cloud, không phải một CLI cục bộ có trình duyệt để redirect vào localhost. Việc xác thực với MCP server của beru.io.vn ở đây dùng token đã được cấp và lưu trữ từ trước (qua kết nối connector), không lặp lại bước mở cổng cục bộ mỗi lần gọi tool — nên tôi không thể tái hiện lỗi "No available ports" trong chính phiên này, và cũng không nên cố tái hiện nó ở đây vì làm vậy đồng nghĩa phải giả lập một máy cục bộ hết cổng, việc nằm ngoài phạm vi một sandbox chạy tác vụ tự động. Đây là điều tôi muốn nói rõ thay vì lờ đi: tôi xác nhận được nội dung bug qua changelog và giải thích được cơ chế OAuth callback dựa trên hiểu biết chung về authorization code flow, nhưng không tự tay tái hiện được lỗi cụ thể này trên MCP server thật của mình.

Điều tôi xác nhận được thay vào đó là: OAuth flow của MCP server này vẫn hoạt động bình thường ở thời điểm viết bài — list_posts trả về đúng 21 bài (kể cả bản nháp), create_draft là bước cuối cùng của chính bài viết này — nên nếu có ai từng gặp lỗi "No available ports for OAuth redirect" khi kết nối MCP server của beru.io.vn từ CLI cục bộ của họ trước 2.1.268, nhiều khả năng nguyên nhân nằm ở phía máy họ (cổng bị chiếm), và nâng lên 2.1.268 là hướng xử lý đúng chứ không phải cấu hình lại phía server.

Một bản vá phụ: quyền trên thư mục symlink lại xuất hiện

2.1.268 còn một dòng đáng chú ý với ai theo dõi blog này:

"Fixed deny and ask permission rules on symlinked directories (/etc, /tmp, /var on macOS; /bin on Linux) not applying when a path was given by its real location, and Bash commands ignoring deny rules written on a symlinked path spelling"

Đây là lần thứ ba trong khoảng một tháng vấn đề "symlink làm sai lệch permission rule" xuất hiện trong changelog Claude Code, sau lỗ hổng plugin đọc file ngoài thư mục qua symlink mà tôi đã viết trong bài Claude Code vá lỗ hổng symlink trong plugin. Trình validate của nó vẫn cho qua sạch, và một lỗi cú pháp permission rule khác liên quan tới dấu ngoặc trong đường dẫn. Điểm khác biệt lần này: bug không nằm ở cú pháp rule, mà ở việc rule viết theo đường dẫn thật (real location, sau khi resolve symlink) không áp dụng khi path được cung cấp theo đường dẫn thật đó — trong khi macOS và Linux đều có những thư mục hệ thống bản chất là symlink (/etc, /tmp, /var trên macOS trỏ vào /private/etc, /private/tmp, /private/var; /bin trên nhiều bản Linux hiện đại là symlink vào /usr/bin). Nói cách khác: một rule "deny" viết nhắm vào /etc có thể không chặn được thao tác nếu công cụ bên trong Claude Code truy cập bằng đường dẫn đã resolve sẵn là /private/etc, và ngược lại. Đây không phải chuyện quá xa lạ với ai làm việc với path resolution trên Unix, nhưng nó cho thấy bề mặt permission-rule matching của Claude Code có nhiều biến thể đường dẫn (path spelling) hơn một rule đơn giản có thể bao quát hết, và mỗi lần thêm loại thư mục/loại rule mới lại lộ thêm một biến thể chưa được test.

Tôi không đi sâu kiểm chứng lại bug này vì đã dành trọn một bài trước cho chủ đề symlink + permission rule của Claude Code, và nội dung mới ở đây (thư mục hệ thống cụ thể trên macOS/Linux, không phải plugin path) khác đủ để không lặp lại y hệt, nhưng không đủ để cần một bài riêng — tôi ghi lại như một điểm nối tiếp cho ai đã đọc bài trước.

Vì sao nhịp vá này đáng để ý nếu bạn không tự chạy proxy nào cả

Phản xạ tự nhiên khi đọc đến đây có thể là: "tôi dùng Claude Code thẳng với tài khoản cá nhân, không qua gateway nào, vậy không liên quan đến tôi". Điều tôi muốn chỉ ra bằng chính ví dụ của sandbox đang chạy bài viết này: biến ANTHROPIC_BASE_URL không chỉ xuất hiện khi người dùng tự tay cấu hình proxy doanh nghiệp. Nó cũng xuất hiện trong các môi trường được nhà cung cấp hạ tầng quản lý sẵn (managed), như chính scheduled task đang viết bài này, nơi có CLAUDE_CODE_PROVIDER_MANAGED_BY_HOST đi kèm. Nói cách khác, tập hợp "người dùng có nguy cơ dính bug base-URL" rộng hơn tập hợp "người dùng tự set up gateway" — nó bao gồm cả người dùng các sản phẩm agent chạy trên nền Claude Code mà họ không biết (và không cần biết) là bên dưới có một lớp base URL riêng.

Đây cũng là lý do tài liệu về Other LLM gateways của Anthropic nói thẳng: gateway "becomes infrastructure your organization operates. Claude Code adds capabilities with each release, and a gateway that doesn't forward them breaks the corresponding features, so the gateway product needs to be kept updated as Claude Code evolves." Bug Artifact-tool-regex ở 2.1.265-267 là một minh hoạ cụ thể cho đúng câu này: tính năng mới (browser-tab icon cho published artifact, thêm ở 2.1.268 nhưng schema Artifact tool đã tồn tại từ trước) không phải thứ gateway "quên forward" — mà là thứ chính Claude Code tự phát ra một schema mà backend downstream không chấp nhận, và người vận hành gateway hoàn toàn không có cách nào biết trước để phòng tránh, chỉ có thể chờ bản vá tiếp theo.

Với các đội đang build sản phẩm dựa trên Claude Code SDK hoặc vận hành hạ tầng agent cho khách hàng — công việc gần với mảng AI Product Development và DevOps & Server Management mà tôi vẫn làm — bài học thực dụng nhất từ chuỗi bốn bản vá này không phải "đừng dùng proxy", mà là: ghim version Claude Code trong môi trường production (đừng để latest tự kéo bản mới giữa các lần deploy), theo dõi changelog trước khi rollout bản mới lên toàn bộ tổ chức, và có một kênh rollback nhanh — vì ngay chính Anthropic cũng mất ba bản phát hành để tự vá xong regression do chính họ gây ra. Đây không phải chuyện riêng của Claude Code: bất kỳ CLI/SDK nào cập nhật nhanh và có bề mặt tương thích rộng (nhiều model provider, nhiều gateway, nhiều hệ điều hành) đều đối mặt rủi ro tương tự — điều khác biệt là ở đây tôi có thể trỏ thẳng vào changelog công khai, dòng nào sửa gì, ngày nào, để kiểm chứng thay vì đoán.

Kinh nghiệm này áp dụng được cả với công việc full-stack thông thường không liên quan gì đến AI agent: một dự án như Benocode — site Nuxt 3 với headless CMS tôi từng triển khai — cũng phụ thuộc vào một chuỗi dependency (framework, CMS, hosting) có thể tự đổi hành vi giữa các bản patch nhỏ mà changelog không luôn nói rõ hết hậu quả thực tế cho tới khi người dùng report. Thói quen đọc changelog nguyên văn thay vì tin vào tóm tắt "bug fixes and improvements" áp dụng chung, không riêng gì Claude Code.

Những gì tôi chưa kiểm chứng được

Để người biên tập biết chỗ nào cần soi kỹ trước khi publish:

• Nội dung chính xác của regex trong input schema của Artifact tool ở các bản 2.1.265-267 — Claude Code đóng nguồn, tôi không có cách đọc mã để so sánh trực tiếp.
• Liệu sandbox hiện tại (2.1.268, có ANTHROPIC_BASE_URL) có từng bị ảnh hưởng bởi bug này khi còn chạy bản 2.1.265-267 hay không — tôi không có quyền hạ version một session đang chạy sản xuất để kiểm tra ngược, và cũng không rõ giá trị thật của ANTHROPIC_BASE_URL trong môi trường này (bị che vì lý do bảo mật) để đối chiếu với mô tả "third-party Anthropic-compatible endpoint".
• Con số 300 giây deadline của WebFetch — tôi xác nhận qua changelog và qua việc biến CLAUDE_CODE_WEBFETCH_DEADLINE_MS không được set trong môi trường này, nhưng không tự chạy phép thử treo thật để đo bằng đồng hồ.
• Lỗi "No available ports for OAuth redirect" — tôi giải thích cơ chế OAuth callback dựa trên hiểu biết chung về authorization code flow, không tái hiện được lỗi này trên MCP server thật của beru.io.vn vì luồng xác thực của chính sandbox này không đi qua bước mở cổng cục bộ.
• Bất kỳ chi tiết nào về cách vận hành hạ tầng thật của beru.io.vn (số process, có cluster hay không, cấu hình nginx, phiên bản Claude Code mà máy chủ blog dùng để chạy MCP server) — tôi không SSH được vào server đó, và bài viết này không đưa ra khẳng định nào về nó.