Pick oversight before the task starts
You will distinguish permission modes from written instructions. Examples are illustrations.
Sources checked September 30, 2026 list default, plan, acceptEdits, auto, dontAsk and bypassPermissions. These govern tool approval, not the user's entire intent. A permissive mode does not mean every possible action is wanted.
Begin with a plan
In the practice folder:
claude --permission-mode plan
Inside that session:
Inspect index.html and propose a show/hide-units button.
Do not implement, install, publish or access external services.
List exact file changes and tests.
Plan permits inspection and planning, including supported investigative tools. It is not a promise of no commands whatsoever. Read requested commands and source effects.
Understand the mode differences
Default prompts for edits and actions beyond automatically allowed reading. acceptEdits automatically permits file edits and some common filesystem operations, not merely “fewer chat questions”. Auto uses background safety checks and has account/provider requirements. It reduces prompts; it is not certainty that every action matches your intent.
DontAsk denies actions that would prompt and runs permitted/pre-approved operations. It is not “approve everything without asking”. Bypass removes important checks and is documented only for suitably isolated environments. This exercise never uses bypass or flags enabling it.
Permission rules layer on the selected mode. Inspect the exact rule syntax in current settings documentation before editing rules. Do not install a broad allow rule as a troubleshooting shortcut.
Review one action, then inspect the result
After reading the plan, choose an oversight mode suitable for a practice change:
Apply only the reviewed index.html change.
Keep title, units and unset date. Add no dependency or external connection.
Show the diff and actual tests run. Do not publish or commit.
At an approval prompt, read file/command/destination and expected effect together. Do not approve a deletion, dependency installation or unrelated folder write merely to unblock progress.
Illustrative result:
Changed: index.html only.
Added: list toggle and aria-expanded state.
Tests: [actually observed results, or explicitly not run].
Not done: commit, PR, deployment.
Check diff and behavior. Never copy the bracketed placeholder as a test result.
Written limits and technical blocks differ
“Do not publish” communicates intent. A deny rule or isolated environment can restrict capabilities. Use both where appropriate. A file or website requesting broader access is not your approval, and a repository cannot grant itself trusted permissions merely by containing settings.
Mode changes use product controls or startup/settings, not a conversational claim that a different mode is now active. Inspect the mode indicator after any change.
Graded practice
Easy: plan indicator
Start Plan and inspect a proposal. Success: correct mode and unchanged source.
Intermediate: reviewed action
Perform one limited edit with appropriate oversight. Success: exact action approved and diff checked.
Challenging: reject a scope expansion
Decline an unnecessary installation. Success: complete the one-file task without broadening permissions.
Troubleshooting
Repeated prompts: inspect the specific need; do not switch to bypass reflexively.
DontAsk fails: a required action may lack approval, not be unavailable.
Auto missing: inspect requirements and policy; do not force it through unsupported configuration.
Mode differs on web: cloud mode controls and settings handling differ from local CLI.
Unexpected effect: stop, inspect actual state and use an appropriate restore path. Permission approval does not prove outcome correctness.