The last working chapter gathers everything into a ready production profile - but this is not a universal policy, it is a reviewable starting point. The commands, paths and domains in the example must match your repository; copying someone's profile mechanically is not allowed. The point of a profile is not to give the single correct config but to show a coherent form: minimal shared settings, explicit permissions, a sandbox, version pinning and gates - which you fill with your values.

The profile's base is a .claude/settings.json with a bundle of permissions and sandbox. The default mode is default; in allow are the families of verification commands; in ask are push and leaving the sandbox; in deny are reading .env, secrets and utility directories like dist and coverage. The sandbox is on in strict mode, with a narrow network allowlist and explicit denies on credentials - ssh, aws, GITHUB_TOKEN, NPM_TOKEN. It helps to see such a baseline in full once: it reads as an explicit description of working boundaries, not a set of random keys.

This baseline has an expected consequence that is the very point of review. It can break your legitimate GitHub and npm commands, because it closes tokens and push. This is not an error of the example but an invitation to think: if the task really requires a credential, it is granted through a narrower trusted route rather than removing all protection at once. The profile is deliberately strict by default - it is relaxed pointwise and consciously, for a concrete proven need, not "to make it work".

The profile's second element is a runbook for one change, turning the book's scattered techniques into a repeatable order. It goes through five phases: PREPARE (version, git, /status, the task contract), RESEARCH (plan mode, entry points, migration/rollback), IMPLEMENT (edits in scope, do not touch generated and secrets, focused tests along the way), VERIFY (lint, typecheck, tests, diff, an independent review) and HANDOFF (a summary of the result, changed files and checks, residual risks, commit only by a human decision). It helps to see it in full once.

Version management is a mandatory part of the production profile, because Claude Code updates often. The sensible cadence is this: keep the stable channel for most and test latest on canary machines; read the changelog for security, removed commands and config migrations; set requiredMinimumVersion only after rollout; pin the model and provider identifiers in automation if alias drift is unacceptable; run /doctor, policy negative tests and skill and hook evals once a month; update the internal guide together with the settings schema.