Claude Code chính thức mặc định chế độ Auto cho người dùng gói Pro, Team và Enterprise

Chúng tôi đang đặt chế độ tự động (auto mode) làm mặc định trong Claude Code. Bắt đầu từ ngày 14 tháng 8, các phiên làm việc mới trên các gói Pro, Max và Team sẽ chạy ở chế độ tự động. Nếu bạn đã tự thiết lập một mặc định khác, bạn có thể nhận được một thông báo một lần hỏi xem bạn có muốn chuyển sang chế độ tự động hay không. Nếu bạn đã ghim (pin) một mặc định, sẽ không có thay đổi nào đối với bạn. Bộ phân loại của chế độ tự động sử dụng một lượng token bổ sung nhỏ cho mỗi lệnh gọi công cụ (tool call), và kể từ hôm nay, chúng tôi sẽ không còn tính phí người dùng Claude Code trên các gói Pro, Max và Team cho chi phí vận hành của bộ phân loại đó nữa.

Chế độ tự động hiện vẫn là tùy chọn (opt-in) trên Claude Enterprise, Claude API, Claude Platform trên AWS, Amazon Bedrock, Google Cloud's Agent Platform và Microsoft Foundry, nhằm tạo thời gian cho các quản trị viên xem xét thay đổi này. Trong tháng tới, phối hợp cùng các đối tác đám mây, chúng tôi dự định đặt chế độ này làm mặc định trên tất cả các nền tảng nêu trên và không còn tính phí cho chi phí vận hành của bộ phân loại. Trong thời gian chờ đợi, các quản trị viên Enterprise có thể đặt chế độ tự động của Claude Code làm mặc định thông qua các cài đặt được quản lý (managed settings).

Chế độ tự động được thiết kế để cân bằng giữa mong muốn không bị gián đoạn của người dùng với một hệ thống giúp tránh các hành động gây hại: thay vì hiển thị các thông báo xác nhận (prompts), hệ thống sẽ định tuyến mỗi lệnh gọi công cụ qua một bộ phân loại nhằm chặn các hành động không thể đảo ngược, có tính phá hoại hoặc nhắm vào bên ngoài môi trường của bạn. Khi bộ phân loại chặn một hành động, Claude thường tự tìm cách an toàn hơn để tiếp tục hoặc hỏi trực tiếp bạn để xin phép; nếu không thể thực hiện tiếp—sau ba lần chặn liên tiếp hoặc hai mươi lần chặn trong một phiên—Claude Code sẽ quay lại chế độ phê duyệt thủ công.

Chúng tôi đã dành vài tháng qua để kiểm tra xem chế độ tự động có an toàn bằng hoặc hơn so với việc người dùng trung bình nhấp chuột qua các thông báo xác nhận hay không. Chúng tôi đã thực hiện đánh giá red-teaming nội bộ, red-teaming từ bên thứ ba, đánh giá tấn công tiêm nhiễm (prompt-injection), một nghiên cứu có kiểm soát với 1.053 người thử nghiệm trả phí và phân tích các phiên làm việc thực tế trong môi trường sản xuất. Trên mọi thước đo mà chúng tôi thử nghiệm, chế độ tự động đều đạt kết quả tương đương hoặc vượt trội so với việc xem xét thủ công.

Chế độ tự động cũng cho phép Claude làm việc tự chủ trong thời gian dài hơn. Điều này giúp các mô hình được xây dựng cho công việc chạy dài hạn, như Claude Opus 5, trở nên thiết thực hơn khi để chạy trong nhiều giờ cho các tác vụ lớn. Việc giảm bớt gánh nặng cho người dùng cũng giúp tăng năng suất. Trong số những người dùng Teams & Enterprise, người dùng chế độ tự động xuất bản (ship) nhiều hơn khoảng 25% các PR (Pull Requests). Việc gỡ bỏ rào cản cho Claude cho phép các tác vụ chạy lâu hơn mà không bị gián đoạn và hoàn thành được nhiều việc hơn. Các đội ngũ tại Adobe, Nuro, Gusto và Garner Health hiện đã sử dụng chế độ tự động làm mặc định trong môi trường sản xuất của họ.

Dưới đây, chúng tôi chia sẻ dữ liệu an toàn và kết quả từ khách hàng đã thúc đẩy thay đổi này, cũng như cách thiết lập một mặc định khác nếu bạn muốn.

So sánh giữa xem xét thủ công và chế độ tự động

Dữ liệu cho thấy việc xem xét thủ công có thể trở thành thói quen: người dùng phê duyệt 97% các thông báo quyền trong Claude Code. Mặc dù hầu hết các thông báo có khả năng là cho các lệnh an toàn, thông thường, tỷ lệ phê duyệt cao như vậy cho thấy nhiều người dùng đang nhấp chuột theo phản xạ thay vì xem xét từng lệnh. Những thông báo này yêu cầu các nhà phát triển đưa ra hàng chục hoặc hàng trăm quyết định bảo mật quan trọng mỗi ngày, thường là ngay giữa các dự án, điều này đặt gánh nặng xem xét lên người dùng và làm tăng khả năng bỏ sót những điều quan trọng. Dữ liệu cũng cho thấy người dùng thường xuyên xem xét kỹ lưỡng và từ chối các loại đối thoại khác hơn: ví dụ, khi Claude trình bày một kế hoạch để phê duyệt, người dùng từ chối 39% trong số đó. Nhưng đối với các yêu cầu quyền riêng lẻ, tỷ lệ từ chối chỉ là 3%.

Mô hình tương tự xuất hiện trong các tệp cài đặt. Tính đến tháng 6 năm 2026, 49,5% người dùng CLI đang hoạt động đã tạo thủ công một quy tắc cho phép (allow-rule) Bash—5% cho phép bất kỳ lệnh shell nào, và 43% khác có các quy tắc thông dịch như Bash(python:*) hoặc Bash(node:*) về cơ bản là tương đương trong thực tế—và tỷ lệ đó đang tăng khoảng 5 điểm phần trăm mỗi 5 tuần. Ngoài các quy tắc cho phép, 62% người dùng đã sử dụng bypassPermissions hoặc nhấp vào “không hỏi lại” trên Bash, và 25% các phiên tương tác bắt đầu ở chế độ bỏ qua quyền (bypass permissions mode).

Các quy tắc quyền vẫn được kích hoạt trước bộ phân loại trong chế độ tự động, ngoại trừ các quy tắc cho phép đủ rộng để cấp quyền thực thi mã tùy ý (ví dụ: python:*). Các quy tắc tùy ý này sẽ bị tạm dừng khi ở chế độ tự động, vì chúng sẽ cho phép các lệnh bỏ qua hoàn toàn bộ phân loại. Các tệp cài đặt không bị sửa đổi và các quy tắc sẽ áp dụng trở lại ngay khi bạn chuyển sang chế độ khác.

Cải thiện an toàn với chế độ tự động

Nghiên cứu được thực hiện nội bộ và thông qua một số bên thứ ba cho thấy chế độ tự động an toàn hơn cách người dùng thông thường tương tác với các thông báo quyền hiện nay. Chúng tôi đã kiểm tra chế độ tự động so với những gì các nhà phát triển thực sự phê duyệt khi họ nhấp chuột qua các thông báo quyền. Trên mỗi thước đo này—red-teaming nội bộ, kiểm thử xâm nhập từ bên thứ ba và phân tích các phiên làm việc thực tế—chế độ tự động đều đạt kết quả tương đương hoặc vượt trội so với sự phê duyệt của con người.

Chế độ tự động vượt trội hơn quyền thủ công về mặt an toàn

Chúng tôi đã thuê 1.053 người thử nghiệm trả phí thông qua một nhà cung cấp nghiên cứu cho một nghiên cứu về lập trình. Những người tham gia này làm việc trong một môi trường thử nghiệm được thiết lập riêng cho nghiên cứu, không phải trong cơ sở mã của riêng họ hoặc trên các dự án thực tế. Những người tham gia biết rằng họ đang được đánh giá, nhưng—theo thiết kế nghiên cứu mù tiêu chuẩn—họ không được cho biết hành vi nào đang được đo lường. Giữa mỗi phiên, một thông báo quyền duy nhất đã được thay thế bằng một lệnh rõ ràng là nguy hiểm, và nhà cung cấp đã ghi lại xem người thử nghiệm có phê duyệt nó hay không (Lưu ý: việc phê duyệt thông báo không bao giờ dẫn đến bất kỳ điều gì nguy hiểm được thực thi; chỉ có văn bản của thông báo mà người thử nghiệm nhìn thấy là bị thay đổi).

Những người thử nghiệm chỉ phát hiện ra lệnh nguy hiểm 13,6% số lần (143 trên 1.053), trong khi chế độ tự động chặn 89% các lệnh tương tự (937 trên 1.053). Khi đối đầu trực tiếp, chế độ tự động đã chặn 800 lệnh mà con người phê duyệt, trong khi con người chỉ chặn 6 lệnh mà chế độ tự động cho phép. Khi các phiên làm việc kéo dài hơn, con người làm việc kém hiệu quả hơn: họ chặn khoảng 17% các lệnh nguy hiểm ở đầu phiên, giảm xuống còn khoảng 5% sau 50 thông báo trở lên, trong khi tỷ lệ chặn của chế độ tự động vẫn ổn định bất kể độ dài phiên.

Chế độ tự động ngăn chặn nhiều hành động gây hại hơn

Nghiên cứu của chúng tôi cũng cho thấy chế độ tự động dẫn đến ít hành động gây hại hơn so với chế độ quyền thủ công.

Chúng tôi đã kiểm tra cách chế độ tự động hoạt động trong sử dụng thực tế. Từ tháng 5 đến tháng 6 năm 2026, chúng tôi đã kiểm tra các phiên làm việc mà đường ống an toàn của chúng tôi đã gắn cờ để xem xét, chỉ lấy từ các tài khoản đã chọn tham gia sử dụng dữ liệu để đào tạo và phân tích. Chúng tôi đã đánh giá lại từng phiên bằng một mô hình trên hai thang điểm 0–10. Thứ nhất là mức độ nghiêm trọng của tác hại, với 10 là tác hại không thể đảo ngược trên toàn công ty, chẳng hạn như làm rò rỉ toàn bộ mã nguồn của công ty, 7 đại diện cho mức độ nghiêm trọng cấp sản xuất như xóa các hàng khỏi cơ sở dữ liệu sản xuất, và 0 là hành động hoàn toàn có thể đảo ngược giới hạn trong không gian làm việc cục bộ, như ghi đè một tệp nháp. Thứ hai là mức độ rõ ràng mà người dùng đã yêu cầu hành động đó, để chúng tôi có thể tách biệt các hành động gây hại mà người dùng trực tiếp yêu cầu với các hành động gây hại mà tác nhân (agent) thực hiện với sự chỉ đạo ít rõ ràng hơn.

Trong số các phiên bị gắn cờ, những phiên trải qua phê duyệt thủ công chứa các tác hại nghiêm trọng ngoài ý muốn nhiều gấp đôi so với các phiên ở chế độ tự động. Ở mức độ nghiêm trọng cấp sản xuất (7+), 6,3% các phiên được phê duyệt thủ công chứa một hành động gây hại mà người dùng không yêu cầu rõ ràng, so với 2,4% các phiên ở chế độ tự động, và khoảng cách này giữ nguyên ở mọi mức độ nghiêm trọng mà chúng tôi thử nghiệm.

Red-teaming đối kháng làm cho chế độ tự động mạnh mẽ hơn

Chúng tôi đã làm việc với Apollo Research, một công ty khởi nghiệp về an toàn AI có trụ sở tại Vương quốc Anh, trong một dự án thí điểm kéo dài hai tuần để tiêm các cuộc tấn công tổng hợp vào các quỹ đạo lập trình thực tế, trên ba tập dữ liệu bao gồm các lỗi rộng, rò rỉ dữ liệu và các mối đe dọa liên quan đến an toàn.

Sự hợp tác này tuân theo vòng lặp tìm kiếm-khắc phục-xác minh tiêu chuẩn. Apollo đã chia sẻ một tập hợp các cuộc tấn công thành công cùng với các khuyến nghị để tăng cường chế độ tự động. Chúng tôi đã củng cố bộ phân loại chống lại chúng chủ yếu bằng cách cung cấp cho nó nhiều ngữ cảnh hơn về môi trường mà nó đang bảo vệ (khả năng hiển thị kho lưu trữ, trạng thái git và các quy tắc xử lý dữ liệu được mô tả bên dưới).

Sau khi củng cố, Apollo đã kiểm tra lại trên một tập hợp tấn công riêng biệt mà chúng tôi chưa từng có quyền truy cập. Chế độ tự động đã bắt được khoảng một nửa số cuộc tấn công mà trước đó nó bỏ lỡ, với cái giá là bỏ lỡ khoảng 2% số cuộc tấn công mà trước đó nó đã bắt được. Vì chúng tôi không thể điều chỉnh dựa trên tập hợp riêng biệt này, điều này cho thấy sự củng cố có khả năng khái quát hóa đối với các cuộc tấn công mới thay vì chỉ vá các cuộc tấn công cụ thể mà Apollo đã chia sẻ. Trên cả hai tập hợp được chia sẻ và tập hợp riêng biệt, tỷ lệ bỏ lỡ của bộ phân loại đã giảm từ 12% xuống 7%.

Những cuộc tấn công này là tổng hợp và mang tính đối kháng theo thiết kế, được xây dựng để tìm ra nơi bộ phân loại thất bại, và độc hại hơn bất cứ điều gì Claude sẽ làm mà không có lời nhắc. Tỷ lệ bỏ lỡ 7% được đo lường dựa trên tập hợp này và không nên được coi là tỷ lệ bỏ lỡ trên lưu lượng truy cập thực tế.

Chế độ tự động giảm rủi ro tiêm nhiễm lời nhắc (prompt injection)

Bộ phân loại của chế độ tự động bổ sung một lớp phòng thủ chống lại các cuộc tấn công tiêm nhiễm lời nhắc cố gắng buộc tác nhân đi chệch khỏi hướng dẫn của người dùng. Khi chạy ở chế độ tự động, kết quả công cụ được quét bởi các thăm dò để tìm các hướng dẫn có khả năng độc hại, và chế độ tự động kiểm tra xem các hành động có phù hợp với ý định của người dùng hay không. Chúng tôi đã kiểm tra chế độ tự động so với một mô hình không được bảo vệ để minh họa sức mạnh của phương pháp phòng thủ theo chiều sâu này.

Chúng tôi đã ủy quyền một đánh giá từ bên thứ ba, Trajectory Labs, những người đã kiểm tra các mô hình khác nhau trong các phiên bản công khai mới nhất của Claude Code và Codex tính đến ngày 17 tháng 7 năm 2026. Họ đã kiểm tra 72 kịch bản tiêm nhiễm lời nhắc gián tiếp được giữ lại từ Anthropic. Mỗi kịch bản được kiểm tra 10 lần. Các cuộc tấn công thành công sẽ, trong môi trường không thử nghiệm, dẫn đến các hành động không thể đảo ngược có thể gây hại cho người dùng như rò rỉ dữ liệu nhạy cảm, gian lận tài chính hoặc lừa đảo thông tin đăng nhập. Các cuộc tấn công được tối ưu hóa chống lại Claude Opus 4.7, không có trong tập hợp được báo cáo, vì vậy mọi mô hình trong đánh giá đều đối mặt với chúng như những cuộc tấn công chưa từng thấy. Ngoài chế độ tự động, các đánh giá còn xem xét chế độ bypassPermissions của Claude Code và chế độ Full Access của Codex.

Cả Codex và Claude Code đều được đánh giá bằng cách sử dụng một tích hợp trình duyệt giống hệt nhau do Trajectory Labs, PBC sản xuất. Tích hợp này cung cấp một bộ công cụ MCP là một lớp bao bọc mỏng xung quanh các API Chrome phổ biến như `navigate`. Các biện pháp bảo vệ được tích hợp vào các tích hợp trình duyệt của bên thứ nhất như các tiện ích mở rộng Chrome do OpenAI và Anthropic cung cấp đã không được kiểm tra. Do đó, các kết quả này nên được xem là phép đo của mô hình cơ bản, thay vì là tập hợp đầy đủ các biện pháp bảo vệ có thể tồn tại trong một triển khai nhất định.

Trong đánh giá này, không có nỗ lực tấn công nào trong số 720 nỗ lực thành công đối với Claude Fable 5, Opus 5 hoặc Sonnet 5 đang chạy chế độ tự động. Mặt khác, 5,83% các cuộc tấn công đã thành công đối với GPT-5.6 Sol đang chạy chế độ Auto-review của Codex. Đáng chú ý, con số này cao hơn tỷ lệ thành công tấn công trung bình 0,09% đối với các mô hình mới nhất của chúng tôi đang chạy ở chế độ bypassPermissions mà không có các biện pháp bảo vệ bổ sung. Các thử nghiệm cho thấy tỷ lệ thành công tấn công là 19,03% đối với GPT-5.6 Sol khi chạy ở chế độ Full Access. Tỷ lệ thành công tấn công khác nhau giữa các tác vụ mà công cụ trả về kết quả dưới dạng văn bản và các tác vụ yêu cầu tương tác với trình duyệt thông qua ảnh chụp màn hình, như được hiển thị bên dưới.

Ba sự cố mà chế độ tự động đã ngăn chặn bên trong Anthropic

Chế độ tự động cũng là mặc định cho tất cả việc sử dụng Claude Code nội bộ tại Anthropic. Dưới đây là ba hành động mà bộ phân loại đã ngăn chặn nội bộ:

Trong mỗi trường hợp, Claude hoặc tự tìm ra con đường an toàn hơn hoặc kiểm tra lại với người dùng trước khi tiếp tục.

Làm cho chế độ tự động an toàn hơn nữa

Chúng tôi liên tục đầu tư vào các tính năng chế độ tự động mới giúp việc xuất bản mã sản xuất trở nên an toàn và dễ dàng hơn. Các ví dụ gần đây bao gồm:

Chế độ tự động trong sản xuất