Đã đăng vào khoảng 9 giờ trước 27 phút đọc

Hướng dẫn cấu hình quyền cho Claude Code bằng settings.json

Mình là Tony, hiện làm và vận hành các sản phẩm web, sử dụng Claude Code làm công cụ phát triển chính hằng ngày. Khi nhờ AI đề xuất code, bạn vẫn quyết định có sử dụng đoạn code đó hay không. Nhưng khi cho Claude Code chạy terminal, sửa file hoặc gọi công cụ bên ngoài, agent có thể trực tiếp thay đổi máy và những hệ thống mà máy của bạn có quyền truy cập.

Bài này thuộc series Claude Code cho dự án thực tế, tập trung vào những vấn đề developer gặp khi đưa Claude Code vào công việc. Nếu bạn đã để agent tự chạy lệnh, chỉnh sửa source hoặc kết nối với database và các công cụ vận hành, bài viết sẽ giúp bạn cấu hình quyền thực thi phù hợp. Sau khi đọc, bạn sẽ có một mẫu settings.json, ma trận phân quyền, checklist bảo vệ dữ liệu và bộ tình huống để kiểm tra policy trước khi áp dụng vào dự án thật.

1. Quyền truy cập thay đổi trách nhiệm của coding agent thế nào?

Trong một phiên làm việc, Claude có thể đọc code, tìm lỗi, sửa implementation và chạy test. Mỗi bước đòi hỏi quyền khác nhau: đọc source giúp agent thu thập thông tin, sửa file tạo thay đổi trong repository, còn chạy lệnh có thể tác động đến filesystem, network hoặc hệ thống bên ngoài. Nếu cấp quyền quá rộng, developer khó kiểm soát agent thực sự được phép làm gì.

Mình dùng một monorepo TypeScript giả định xuyên suốt bài viết. Repository sử dụng pnpm, có ứng dụng quản trị tại apps/admin, API tại apps/api, thư viện giao diện tại packages/ui và các thành phần dùng chung tại packages/shared. API phục vụ nhiều tổ chức khách hàng, mỗi request phải được giới hạn theo tenant để tránh truy cập dữ liệu của tổ chức khác. Team còn có database, CI và công cụ quản lý hạ tầng.

workspace/
├── apps/
│   ├── admin/
│   └── api/
├── packages/
│   ├── ui/
│   └── shared/
├── .claude/
│   └── settings.json
├── pnpm-workspace.yaml
└── package.json

Giả sử bạn giao cho Claude sửa một API endpoint trả về dữ liệu sai tenant. Agent cần đọc implementation, tìm test, sửa code và chạy pnpm -F api test. Những thao tác này phục vụ phát triển cục bộ, không đòi hỏi quyền truy cập production database hay deployment. Mình tách hoạt động của agent thành bốn mức để xác định quyền tương ứng.

Mức	Agent làm gì	Ví dụ trong repository
Đề xuất	Phân tích và đưa ra hướng xử lý	Đề xuất kiểm tra tenant trong API
Đọc	Lấy thông tin từ repository hoặc tool	Đọc route handler và test
Chỉnh sửa	Thay đổi nội dung trong workspace	Sửa test và implementation
Thực thi	Chạy lệnh hoặc tác động tới hệ thống	Chạy test, cài dependency, gọi API bên ngoài

Hai thao tác cùng dùng terminal chưa chắc có cùng mức rủi ro. pnpm -F api test thường phục vụ kiểm tra cục bộ, còn một lệnh kết nối production database có thể thay đổi dữ liệu khách hàng. Tương tự, một MCP tool xem trạng thái hệ thống khác với tool cập nhật cấu hình hạ tầng. Policy cần phản ánh tác động thực tế, thay vì chỉ dựa trên tên công cụ.

2. Hiểu mô hình permissions của Claude Code

Claude Code quản lý quyền bằng các rule trong settings.json. Lệnh /permissions cho phép xem, thêm, xóa rule và kiểm tra rule đến từ file settings nào. Claude Code thực thi permission rules ở lớp công cụ, không dựa vào chuyện model có ghi nhớ instruction hay không.

Ba loại rule: allow, ask và deny

Trong mục permissions, Claude Code hỗ trợ ba danh sách:

allow: Agent được gọi tool phù hợp mà không cần hỏi.
ask: Claude Code yêu cầu xác nhận mỗi khi thao tác khớp rule.
deny: Claude Code chặn thao tác khớp rule.

Ví dụ cấu hình:

{
  "permissions": {
    "allow": [
      "Bash(pnpm -F api test)"
    ],
    "ask": [
      "Bash(pnpm install)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)"
    ]
  }
}

Agent được chạy đúng lệnh test API mà không cần hỏi, nhưng phải xin phép trước khi chạy pnpm install. Các rule Read chặn thao tác đọc trực tiếp những đường dẫn nhạy cảm đã khai báo. Chúng chưa ngăn được mọi cách truy cập gián tiếp.

Claude Code xét rule theo thứ tự deny, sau đó ask, cuối cùng allow. Nếu một thao tác khớp nhiều rule, loại có độ ưu tiên cao hơn quyết định kết quả. Chẳng hạn, deny Bash(npm run *) sẽ chặn cả Bash(npm run build), dù bạn thêm lệnh build vào allow.

Phân quyền theo mức tác động

Cú pháp rule cần nắm

Với Bash, Claude Code hỗ trợ lệnh chính xác hoặc wildcard. Với Read và Edit, bạn giới hạn theo đường dẫn. Với MCP, bạn có thể chọn một tool hoặc toàn bộ tool của server.

Rule	Ý nghĩa
`Bash(npm run build)`	Khớp lệnh build chính xác
`Bash(npm run *)`	Khớp các lệnh bắt đầu bằng `npm run`
`Bash(npm run test:*)`	Khớp các lệnh bắt đầu bằng `npm run test:`
`Read(./.env)`	Khớp thao tác đọc file `.env`
`Read(./secrets/**)`	Khớp thao tác đọc trong cây thư mục secrets
`Edit(/docs/**)`	Khớp thao tác chỉnh sửa trong docs
`WebFetch(domain:example.com)`	Khớp WebFetch tới domain được chỉ định
`mcp__puppeteer__*`	Khớp mọi tool của MCP server puppeteer
`mcp__puppeteer__puppeteer_navigate`	Khớp riêng tool điều hướng

Pattern đường dẫn sử dụng cú pháp tương tự gitignore. Với đường dẫn bắt đầu bằng / như Edit(/docs/**), Claude Code tính từ thư mục chứa file settings, nên vị trí đặt settings ảnh hưởng đến đường dẫn được áp dụng. Để giới hạn quyền chỉnh sửa, dùng Edit(...) thay vì Write(...), vì rule Write(...) không khớp.

Settings được đặt ở đâu?

Claude Code cho phép cấu hình ở nhiều cấp. User settings dành cho cá nhân, project settings chia sẻ policy trong repository, còn local settings dành cho điều chỉnh riêng của từng developer. Managed settings cho phép tổ chức kiểm soát những giới hạn chung.

Vị trí	Phạm vi	Cách dùng
`~/.claude/settings.json`	User	Quyền mặc định của cá nhân
`.claude/settings.json`	Project	Quyền chung được commit cùng repository
`.claude/settings.local.json`	Local	Quyền riêng của developer trong dự án
Managed settings	Tổ chức	Policy do tổ chức kiểm soát

Claude Code lưu những lựa chọn cấp quyền lâu dài từ "don't ask again" vào local settings. Vì thế, khi agent có quyền khác với project settings, mình kiểm tra cả cấu hình user và local bằng /permissions. Managed settings có ưu tiên cao nhất và không thể bị ghi đè, còn deny ở bất kỳ cấp nào cũng thắng allow từ cấp khác.

Permission modes không thay thế permission rules

defaultMode quyết định cách Claude Code xử lý quyền trong một phiên làm việc. Mode xác định mức tự chủ chung, còn allow, ask và deny đặt ranh giới cho từng thao tác. Hai phần cần được cấu hình cùng nhau.

Mode	Cách hoạt động
`default`	Hỏi khi lần đầu sử dụng tool cần quyền
`acceptEdits`	Tự nhận sửa file và một số lệnh filesystem thường gặp
`plan`	Đọc, khảo sát và lập kế hoạch, không sửa source
`auto`	Tự chạy các thao tác thường gặp, có bộ phân loại nền xem xét hành động
`dontAsk`	Từ chối thao tác cần hỏi, vẫn chạy tool đã được cho phép
`bypassPermissions`	Bỏ qua bước hỏi quyền

plan phù hợp khi Claude cần khảo sát trước khi sửa code, còn dontAsk phù hợp với workflow không thể dừng để xin xác nhận. auto cho phép agent chủ động hơn nhưng vẫn có cơ chế xem xét hành động. Riêng bypassPermissions chỉ phù hợp với môi trường đã được cách ly.

{
  "permissions": {
    "defaultMode": "default",
    "disableBypassPermissionsMode": "disable"
  }
}

Cấu hình này giữ mode mặc định và vô hiệu hóa chế độ bypass permissions. Mình chọn cách đó để quyền chạy tự động đến từ những allow rules đã xác định, thay vì bỏ qua toàn bộ bước xác nhận. Team vẫn có thể mở rộng policy khi cần.

Nguồn tham khảo chính thức:

3. Phân loại thao tác theo mức rủi ro

Trước khi viết policy, mình liệt kê những thao tác agent thường thực hiện và hệ thống chúng có thể tác động. Với monorepo giả định, đọc code API không cùng mức rủi ro với đọc credentials, dù cả hai đều là thao tác đọc. Chạy test cục bộ cũng khác với chạy database migration trên production.

Mình phân loại theo ba yếu tố: tài nguyên được truy cập, hậu quả có thể xảy ra và mức độ dễ kiểm tra hoặc hoàn tác. Ma trận dưới đây áp dụng cho repository giả định, không phải bảng phân loại cố định cho mọi dự án. Team cần điều chỉnh theo cách scripts và công cụ thực sự hoạt động.

Loại thao tác	Ví dụ	Rủi ro	Chính sách đề xuất
Đọc source	Xem code API, UI, shared	Thấp	Allow
Chỉnh sửa code	Sửa implementation, test	Trung bình	Cho phép trong phạm vi công việc
Chạy test	`pnpm -F api test`	Thấp	Allow
Build	Build ứng dụng cục bộ	Thấp đến trung bình	Allow theo lệnh
Cài dependency	`pnpm install`	Trung bình	Ask
Đọc credentials	Đọc `.env`, secrets	Cao	Deny
Gọi external tool	Tool đọc hoặc thay đổi hệ thống	Phụ thuộc tool	Ask theo phạm vi
Database migration	Thay đổi schema hoặc dữ liệu	Cao	Phê duyệt riêng
Deployment	Triển khai ứng dụng	Cao	Phê duyệt riêng
Production data	Truy cập hoặc thay đổi dữ liệu thật	Rất cao	Không cấp trong workflow thông thường

Một bộ test có thể gọi dịch vụ ngoài nếu môi trường test được cấu hình như vậy. Lệnh cài dependency cũng có thể thực thi code từ package được cài đặt. Mình chỉ đưa lệnh vào allow sau khi hiểu nó thực sự làm gì, thay vì mặc định những lệnh quen thuộc đều an toàn.

Với API đa tenant, permission policy không kiểm tra được logic cách ly dữ liệu. Claude có thể chạy test thành công nhưng vẫn bỏ sót một đường truy cập dữ liệu khác. Test và code review tiếp tục chịu trách nhiệm xác minh nghiệp vụ, còn permissions giới hạn quyền thực thi của agent.

4. Thiết kế quyền cho workflow phát triển thông thường

Mình muốn Claude tự chạy test và build đã biết, nhưng vẫn hỏi trước khi cài dependency hoặc gọi công cụ bên ngoài. Các đường dẫn chứa secrets được deny để ngăn truy cập trực tiếp. Với workflow này, .claude/settings.json có thể bắt đầu như sau:

{
  "permissions": {
    "defaultMode": "default",
    "disableBypassPermissionsMode": "disable",
    "allow": [
      "Bash(pnpm -F api test)",
      "Bash(pnpm -F admin test)",
      "Bash(pnpm -F api build)",
      "Bash(pnpm -F admin build)"
    ],
    "ask": [
      "Bash(pnpm install)",
      "Bash(pnpm add *)",
      "WebFetch(domain:example.com)",
      "mcp__puppeteer__puppeteer_navigate"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Edit(./.env)",
      "Edit(./.env.*)",
      "Edit(./secrets/**)"
    ]
  }
}

Những lệnh pnpm phản ánh scripts của repository giả định, nên cần đối chiếu với workspace thật trước khi sử dụng. example.com đại diện cho domain thử nghiệm, không phải địa chỉ cần giữ nguyên trong dự án. Cấu hình cũng không allow toàn bộ Bash hoặc tất cả MCP tools.

Mình không dùng Bash(pnpm *) vì rule này có thể bao phủ nhiều lệnh ngoài workflow phát triển cục bộ. Thay vào đó, mình khai báo chính xác các lệnh test và build đã biết. Những thao tác chưa khớp allow sẽ được Claude Code xử lý theo các rule và permission mode còn lại.

Với chỉnh sửa source, mẫu này không đặt deny rộng cho repository. Nếu chuyển sang acceptEdits, Claude Code có thể tự nhận sửa file và một số lệnh filesystem như mkdir, touch, mv, cp trong thư mục làm việc. Team cần tính cả những thao tác này khi quyết định mức tự chủ phù hợp.

Cẩn thận khi mở quyền cho MCP

Một MCP server có thể cung cấp nhiều tool, từ đọc thông tin đến điều khiển hệ thống bên ngoài. Allow toàn bộ server có thể cấp nhiều quyền hơn workflow thực sự cần. Mình ưu tiên cấp quyền theo từng tool và kiểm tra tham số mà tool nhận được.

Hai rule dưới đây có phạm vi khác nhau:

mcp__puppeteer__*
mcp__puppeteer__puppeteer_navigate

Rule đầu khớp mọi tool của MCP server puppeteer, còn rule thứ hai chỉ khớp tool điều hướng. Tuy nhiên, quyền gọi một tool chưa xác định được mọi hành động phía sau nó. Nếu tool nhận URL từ agent, cùng một quyền có thể được dùng để truy cập nhiều địa chỉ, kể cả những hệ thống ngoài phạm vi công việc.

Bài về kiểm tra giao diện web bằng Playwright trong series sẽ đi sâu vào cách agent thao tác với browser để xác minh kết quả. Ở đây, mình chỉ tách rõ quyền gọi browser tool và quyền thực hiện hành động trong phiên browser. Hai phạm vi này cần được kiểm soát riêng.

Khi instruction không đủ để giới hạn quyền

Bạn có thể ghi trong CLAUDE.md rằng agent không được truy cập production database hoặc phải hỏi trước khi deployment. Instruction giúp Claude hiểu quy trình, nhưng Claude Code không dùng nội dung đó để cấp hoặc thu quyền ở lớp thực thi. Muốn kiểm soát lời gọi tool, team phải dùng permissions hoặc cơ chế thực thi phù hợp.

Skill cũng có vai trò tương tự ở điểm này. Một Skill có thể hướng dẫn Claude đọc code, sửa test, chạy kiểm tra và báo cáo theo quy trình, nhưng không tự thay đổi permission rules. Mình sẽ đi sâu hơn trong bài về Skills của series.

Nếu cần hiểu cách cung cấp bối cảnh và instruction cho Claude, bạn có thể đọc Hướng dẫn viết CLAUDE.md để Claude Code hiểu đúng dự án của bạn. Bài đó tập trung vào cách Claude hiểu dự án. Bài này xử lý ranh giới thực thi.

5. Bảo vệ secrets và dữ liệu nhạy cảm

Repository có database, CI và công cụ hạ tầng thường đi kèm credentials. Developer có thể dùng chúng để kết nối tới những hệ thống đã được phân quyền, còn agent có thể gặp các quyền truy cập đó khi chạy công cụ trong cùng môi trường. Deny một số file .env chưa đủ để bảo vệ toàn bộ dữ liệu nhạy cảm.

Mình bắt đầu bằng cách chặn Read và Edit tại những đường dẫn đã xác định:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Edit(./.env)",
      "Edit(./.env.*)",
      "Edit(./secrets/**)"
    ]
  }
}

Những rule này chặn thao tác trực tiếp khi đường dẫn khớp pattern. Chúng không tạo ra ranh giới bảo mật ở cấp hệ điều hành, vì lệnh Bash như grep -r hoặc script tự mở file vẫn có thể truy cập dữ liệu gián tiếp. .claudeignore cũng không phải cơ chế chặn đọc file của Claude Code, nên không thể dùng thay cho deny Read.

Tool output là một đường truy cập khác cần xem xét. Giả sử agent gọi công cụ kiểm tra môi trường và công cụ trả về cấu hình chứa token, Claude có thể nhìn thấy thông tin đó dù không đọc file secrets. Permission rule kiểm soát lời gọi tool, nhưng không tự lọc dữ liệu nhạy cảm trong kết quả trả về.

Permissions và sandbox bảo vệ hai lớp khác nhau

Claude Code hỗ trợ sandbox để giới hạn filesystem và network ở cấp hệ điều hành đối với Bash. Permissions quyết định lời gọi tool có được thực hiện hay không, còn sandbox giới hạn tài nguyên mà lệnh có thể truy cập. Mình sử dụng cả hai vì một lệnh được allow vẫn có thể thực thi code với tác động rộng hơn tên lệnh thể hiện.

Giả sử pnpm -F api test gọi một script truy cập file ngoài workspace. Permission có thể cho chạy lệnh test vì nó khớp allow, nhưng không tự giới hạn mọi thao tác bên trong script. Sandbox bổ sung giới hạn ở lớp hệ điều hành, còn môi trường thử nghiệm cần được tách khỏi credentials và dữ liệu production.

Vì sao deny theo tiền tố Bash không đủ?

Rule Bash theo tiền tố chỉ khớp những lệnh có cú pháp phù hợp. Chẳng hạn, Bash(curl *) không bắt /usr/bin/curl hoặc sh -c 'curl ...'; Bash(git push *) cũng không bắt git -C . push. Vì vậy, deny một tên lệnh không đồng nghĩa chặn được mọi cách thực hiện hành vi tương ứng.

Claude Code có thể tách lệnh ghép và kiểm tra từng lệnh con với allow rules. Nhưng các chương trình như npx hoặc docker exec không được bóc tách theo cùng cách, nên allow rộng chúng có thể mở ra những thao tác ngoài dự kiến. Mình ưu tiên cấp quyền cho những lệnh cụ thể và giới hạn môi trường thực thi, thay vì cố xây một danh sách deny bao phủ mọi biến thể.

6. Kiểm thử chính sách với hành động được phép và bị chặn

Một file JSON hợp lệ chưa chứng minh policy hoạt động đúng. Nhiều cấp settings, wildcard và permission modes có thể tạo ra kết quả khác với suy đoán. Mình kiểm tra trong repository giả lập, có cấu trúc gần giống dự án thật nhưng không kết nối production.

Repository thử nghiệm vẫn gồm apps/admin, apps/api, packages/ui và packages/shared. Mình chuẩn bị .env và thư mục secrets chứa dữ liệu giả, cùng những scripts test và build chạy cục bộ. Sau đó, mở /permissions để xem các rule đang có hiệu lực và nguồn cấu hình.

Bộ kiểm thử policy

Với mẫu settings.json ở phần 4, mình dùng tám tình huống sau:

Tình huống	Hành động thử	Kết quả mong đợi
1	Chạy `pnpm -F api test`	Allow, không hỏi
2	Chạy `pnpm -F admin build`	Allow, không hỏi
3	Chạy `pnpm install`	Ask
4	Chạy `pnpm add example-package`	Ask
5	Đọc trực tiếp `.env` bằng Read	Deny
6	Đọc file trong `secrets` bằng Read	Deny
7	Chỉnh sửa file trong `secrets` bằng Edit	Deny
8	Gọi `mcp__puppeteer__puppeteer_navigate`	Ask

Khi thử allow, mình kiểm tra tool có chạy mà không hỏi hay không. Với ask, Claude Code phải dừng để người dùng xác nhận trước khi thực hiện. Với deny, lời gọi tool phải bị chặn, thay vì agent chỉ trả lời rằng nó sẽ không làm.

Kiểm thử permission policy trước khi dùng thật

Thử cả những trường hợp dễ hiểu sai

Mình thêm deny Bash(npm run *) và allow Bash(npm run build) trong môi trường thử nghiệm. Kết quả mong đợi là lệnh build vẫn bị chặn vì deny ưu tiên cao hơn allow. Sau đó, mình thử một lệnh không khớp allow để quan sát cách default và dontAsk xử lý.

Trong default, Claude Code có thể yêu cầu xác nhận theo cơ chế permission tương ứng. Khi chuyển sang dontAsk, những thao tác cần hỏi bị từ chối, còn tool đã allow vẫn chạy được. Điều này giúp kiểm tra mode có phù hợp với workflow dự định hay không.

Một tình huống khác là yêu cầu agent dùng grep -r tìm chuỗi giả trong thư mục secrets. Nếu Bash được phép chạy, deny Read không nhất thiết chặn được truy cập gián tiếp này. Kết quả thử nghiệm cho thấy rõ giới hạn của permission rules và lý do cần sandbox.

Dùng PreToolUse hook khi rule chưa diễn đạt đủ

Permission rules phù hợp với tên tool, lệnh và pattern, nhưng đôi khi team cần kiểm tra tham số thực tế như URL đích. Claude Code hỗ trợ PreToolUse hook chạy trước bước hỏi quyền. Hook có thể kiểm tra đầu vào để quyết định có chặn tool hay không.

Hook trả allow không thể vượt qua deny hoặc ask, còn hook kết thúc với mã thoát 2 sẽ chặn tool ngay cả khi đã có allow. Với browser tool, team có thể xây hook kiểm tra domain trước khi agent điều hướng. Logic cụ thể phụ thuộc vào tool và danh sách domain được duyệt, nên phải được triển khai và kiểm thử riêng.

Claude Code xét quyền theo thứ tự nào

7. Khi nào bắt buộc có xác nhận của con người?

Với deployment, database migration hoặc thay đổi dữ liệu khó hoàn tác, một rule ask chưa đủ thay thế quy trình phê duyệt. Người xác nhận cần hiểu môi trường đích, phạm vi tác động và phương án khôi phục. Mình tách các thao tác phát triển cục bộ khỏi những hành động có thể ảnh hưởng đến hệ thống đang vận hành.

Trong monorepo giả định, Claude được đọc source, sửa code và chạy test theo policy. Agent có thể chuẩn bị migration hoặc bản build, nhưng người phụ trách phải xem xét trước khi thực thi trên production. Team cũng cần xác định ai có quyền phê duyệt thay vì để bất kỳ phiên Claude Code nào thực hiện thao tác đó.

Trước khi phê duyệt, mình dùng sáu câu hỏi:

Tài nguyên đích: Agent sẽ tác động tới development, staging hay production?
Phạm vi thay đổi: Thao tác ảnh hưởng một ứng dụng, một tenant hay toàn bộ database?
Lệnh hoặc tool: Agent định chạy lệnh nào, với tham số và quyền gì?
Khả năng hoàn tác: Nếu xảy ra lỗi, team có phương án khôi phục không?
Bằng chứng kiểm tra: Test, build hoặc các bước xác minh cần thiết đã đạt yêu cầu chưa?
Người chịu trách nhiệm: Ai phê duyệt và theo dõi kết quả?

Với database migration, Claude có thể chuẩn bị code và mô tả phạm vi thay đổi. Người phụ trách database xem xét trước khi cho chạy trên production. Với deployment, agent chuẩn bị bản build và thông tin phiên bản, còn bước phát hành tuân theo quy trình của team.

Khi tool được phép nhưng hành động vẫn vượt phạm vi

Giả sử team allow một MCP tool kiểm tra hạ tầng, còn phiên kết nối có quyền tới cả staging và production. Agent có thể gọi đúng tool được allow nhưng truyền tham số trỏ tới production. Permission rule cho phép lời gọi, trong khi quyền thực tế phụ thuộc vào tham số và hệ thống phía sau.

Mình xử lý bằng cách kiểm tra tham số của tool, yêu cầu xác nhận khi cần và giới hạn credentials theo môi trường. Nếu agent chỉ làm việc với staging, phiên kết nối cũng chỉ nên có quyền staging. Khi quyền ở hệ thống đích đã được giới hạn, sai sót trong permission policy khó dẫn tới thay đổi ngoài phạm vi được giao.

Checklist trước khi áp dụng vào repository

Mình dùng checklist này khi thêm tool hoặc cập nhật quyền cho team. Những mục liên quan đến tool access cần được kiểm tra trên môi trường thử nghiệm trước khi cấp quyền rộng hơn. Nếu chưa xác định được tác động của một thao tác, mình giữ bước xác nhận.

Cấu hình quyền

[ ] Project settings chỉ allow các lệnh team đã xác định rõ hành vi.
[ ] Các lệnh cài dependency cần xác nhận trước khi chạy.
[ ] Không sử dụng bypassPermissions trong môi trường làm việc thông thường.
[ ] Kiểm tra user settings, project settings, local settings và managed settings nếu có.
[ ] Xem rule thực tế bằng /permissions.

Secrets và môi trường

[ ] Có deny Read và Edit cho những đường dẫn nhạy cảm đã xác định.
[ ] Không coi deny là sandbox hoặc cơ chế chặn mọi truy cập gián tiếp.
[ ] Môi trường thử nghiệm không chứa credentials production.
[ ] Kiểm tra dữ liệu có thể xuất hiện trong tool output.
[ ] Dùng sandbox để bổ sung giới hạn filesystem và network cho Bash.

Tool và hệ thống bên ngoài

[ ] Kiểm tra phạm vi từng MCP tool trước khi allow.
[ ] Không cấp quyền toàn bộ MCP server nếu workflow chỉ cần một tool.
[ ] Xác định URL và tài nguyên mà agent có thể truy cập.
[ ] Các thao tác deployment, migration và thay đổi production phải có quy trình xác nhận riêng.
[ ] Kiểm thử allow, ask, deny và các trường hợp truy cập gián tiếp bằng dữ liệu giả.

Kết luận

Khi Claude Code được quyền thực thi, developer cần xác định rõ thao tác nào được chạy tự động và thao tác nào phải dừng để xác nhận. settings.json giúp kiểm soát các lời gọi tool bằng allow, ask và deny, nhưng không tự bảo vệ mọi tài nguyên mà tool có thể truy cập. Sandbox, hooks và quyền của hệ thống bên ngoài bổ sung những giới hạn cần thiết.

Với dự án thực tế, mình bắt đầu từ những quyền nhỏ và có thể kiểm tra: đọc source, sửa code trong phạm vi công việc, chạy test và build đã biết. Sau đó, team mở thêm quyền dựa trên nhu cầu và tác động thực tế. Trước khi áp dụng policy vào repository thật, mình kiểm tra các trường hợp allow, ask, deny trong môi trường giả lập, rồi rà lại secrets, sandbox và các kết nối bên ngoài.

Các bài trong series

Series Claude Code cho dự án thực tế, mỗi bài trả lời một câu hỏi dev hay gặp khi đưa Claude Code vào dự án thật:

Bài tiếp theo trong series: Hướng dẫn dùng Claude Code và Playwright để kiểm tra giao diện web.