Imagine a modest request: fix a label that disappears on mobile. While finding the component, a coding agent reads configuration, runs a package script and encounters credentials available to the process. The same environment might also permit a remote push or deployment. This is a hypothetical failure path, not a reported incident. The requested change is small; the available authority may not be.
Before staff grant repository access, an engineering owner needs evidence about this repository, this execution environment and this task. What material may be exposed? Which actions are permitted? Can access be stopped, and can someone independently verify and recover the work?
The preflight below is an editorial control recommendation, not a product safety guarantee. Passing it supplies evidence for an authorised owner’s decision; it does not grant access by itself.
Start here
Delegation decision: decide whether to hand over the assignment.
Claude Code product boundary: identify the product, model, account and environment.
Evaluation: measure accepted work and human effort.What may an AI agent read or change? supplies the general authority model. This page applies it to a repository.
1. Establish whether the material may be exposed
Classify the proposed checkout before giving the agent access. Consider customer source code, personal information, incident notes, licensed assets and fixtures derived from real records. Include reachable Git history, submodules, adjacent directories, mounted volumes and connected services—not just files expected to change.
Name the person authorised to decide whether that material may enter the chosen product and workflow. They may need privacy, contractual or security advice. Record the decision and its limits; do not infer permission from an employee’s existing repository access.
Keep this inspection within existing authorised human processes. Do not give the agent access so it can decide whether access was permissible. Removing a customer name from one fixture is not evidence that the rest is cleared.
Check credentials separately: environment variables, local configuration, package-manager credentials, SSH agents, cloud profiles and CI tooling. Record exposure categories and control evidence, never secret values. For this bounded workflow, production credentials must not be available. If they are necessary to perform the proposed task, hold and redesign it.
2. Separate the rights a bugfix could exercise
A general “repository access” decision is too vague. Record each right separately, even when one tool can exercise several:
- Read: which source files, history and supporting material may be inspected?
- Edit: which files may change, and which paths remain outside scope?
- Command execution: which scripts or programs may run, with what working directory and inherited environment?
- Dependencies: may packages be downloaded, installed or updated? Are installation scripts permitted?
- Credentials: which identities, if any, are available? Do not bundle credential access into test permission.
- Network and connected tools: which destinations and operations are necessary? Separate product-service connections from task integrations.
- Commit: may local history be created or changed? Check relevant hooks before allowing it.
- Push and shared actions: may anything reach a remote branch, pull request, ticket or recipient?
- Deployment: keep release and production changes outside the local bugfix permission.
Claude Code’s overview documents file editing, command execution, Git workflows and external tool connections. Those are capabilities to investigate, not proof that an installed session has—or lacks—those rights. Claude Code overview
Repository instructions are not grants of authority. Claude Code’s documentation distinguishes prompt and CLAUDE.md instructions from permission rules enforced by the product. A request saying “only fix the label” does not change those rules. Claude Code permissions
Nor does an approval prompt prove downstream restriction. An allowed command may invoke scripts using other resources. Inspect the effective configuration and relevant environment controls, then test the intended boundary in isolation.
3. Isolate changes and inspect executable dependencies
Record a clean starting snapshot and give the task a dedicated branch or worktree, without unrelated human changes. This separates the proposed diff; it does not by itself isolate credentials, network access, shared Git state or other checkouts.
Use the chosen tool’s current documentation and the actual installed version. Record where effective permissions come from and who can change them. Do not assume that another product—or another surface of the same product—has an identical sandbox.
Before permitting a test command, inspect its scripts and dependencies. “Run tests” may conceal downloads, setup hooks or remote calls. Establish a baseline using authorised checks so later failures can be distinguished from existing ones.
Record lockfiles and the current dependency state. New packages, licence changes, build scripts or downloads require explicit review rather than being accepted as incidental setup. If needed, pause for the appropriate decision; this checklist provides no legal assurance about a licence.
4. Test a denied path using synthetic material only
The following design is fictional and unexecuted. It uses a disposable appointment-page application with invented code and data. No client content, real secret, recipient, production resource or third-party destination participates.
Before any denied-path, revocation, process-stop or recovery exercise in sections 4–5, have an authorised human independently verify the disposable environment’s containment. Do not expose actual secrets, client material, host credentials or non-test mounts. Disable real task integrations and prevent test commands, hooks, subprocesses and connected tools from reaching real recipients, production endpoints or other external task destinations.
If the chosen product requires a service connection, authorise it separately and send only invented test material; that connection does not authorise task-driven external actions.
Verify these boundaries through configuration and existing authorised evidence, not by probing real resources. If containment cannot be established, hold the exercises.
Inside that environment, create a permitted worktree and a separate dummy directory outside the permitted path. Put harmless, clearly labelled invented text in the dummy directory; do not imitate a usable credential.
Before starting, verify that the fixture exists. Then attempt the denied read through a known tool route under the intended controls, with a human supervising. Preserve non-sensitive evidence of the attempted path and the control’s response.
A useful observation is an explicit enforcement denial, independently checked against the configuration and execution record. The agent merely saying “I cannot do that” proves nothing about filesystem access. A missing file or failed command is also not necessarily a permission denial.
If the read succeeds, hold. If no actual attempt occurs or the reason for failure is unclear, mark the check inconclusive, not passed. Do not encourage improvisation around the boundary. Where several permitted tools could reach the same resource, identify the relevant routes; testing one route does not establish that all others are restricted.
A local synthetic endpoint can similarly stand in for a prohibited network destination, provided it is contained within the disposable environment and cannot forward traffic. Its observations establish only that test’s result—not a blanket claim that external access is blocked. Never probe a real destination to demonstrate denial.
5. Verify revocation, then recovery
Inside that same verified disposable environment, design a separate revocation check using one harmless capability, such as writing to a scratch file. Confirm it works initially, revoke it through the chosen setup’s documented mechanism, and observe whether the next attempted action is denied.
Record when the change takes effect. Do not assume every product updates permissions mid-session. If a restart is required, document and verify that sequence. If live revocation is required but unavailable, hold that workflow.
Check the distinction between future actions and existing processes. Removing permission for the next tool call does not, by itself, demonstrate that a command already running has stopped. Using only a disposable local process, verify the operator’s documented stop procedure and independently confirm it has ended.
Then preserve the test evidence, inspect the changes and restore or recreate the disposable checkout from its known snapshot. Verify that no test process or unintended access remains. Do not practise recovery by resetting a real developer’s working tree.
All results here remain unknown—unrun. A successful synthetic exercise would not certify a real repository. Map the tested controls to the proposed real environment and investigate differences before seeking access approval.
6. Reserve independent review and a human recovery path
Name a supervisor, an independent reviewer and the person able to stop execution or revoke access. Agree stop triggers: unexpected paths, credentials, destinations, dependency changes, unexplained failures or the task’s time/spend ceiling.
Specify acceptance evidence before the run. Include relevant tests and independent checks of the user-visible outcome. For the mobile-label example, review the actual rendering at relevant widths, keyboard interaction and applicable light/dark or reduced-motion states. Automated checks alone do not establish usability.
The reviewer should inspect the whole diff, including tests, scripts, lockfiles and generated files. Preserve failed and unrun checks. The agent’s completion summary is an input to review, not acceptance evidence on its own.
Plan rollback without erasing human work: retain the base snapshot, isolate the agent’s changes and identify who may discard or recover them. Restoring code cannot retract an external message or contain a credential exposure. Unexpected external effects require separate containment and escalation.
Keep pushing, opening pull requests, messaging, changing CI and deploying subject to their own explicit decisions. Permission to create a local commit is not permission to publish it.
Copyable repository preflight and handoff
Repository / authorised owner / task / base snapshot: ___
Classification and approval for this product/workflow: ___
Reachable history, adjacent paths and integrations checked: ___
Credential exposure and isolation evidence—no secret values: ___
Execution environment / dedicated branch or worktree: ___
Product/version and verified configuration record from the Claude Code product-boundary guide: ___
Read / edit / command rights: ___
Dependency / credential / network and tool rights: ___
Local commit / push / deployment rights—separately decided: ___
Denied-path evidence / limitations / date: ___
Revocation and process-stop evidence / recovery result: ___
Baseline, completion and visual/user-outcome checks: ___
Supervisor / independent reviewer / stop contact / ceilings: ___
Rollback method and protected human work: ___
Handoff: diff, actions, tests, failures, unknowns: ___
Owner’s scoped access decision and conditions: ___
Decision: proceed only within an explicit repository-specific authorisation. If classification, effective controls, negative-test evidence, review ownership or recovery remains unresolved, hold real access. Resolve the gap without exposing the material first. Neither a green checklist nor an approval button replaces the authorised owner’s decision.