You cannot reliably stop every prompt injection attempt with a special coding-agent instruction. I would instead prepare a restricted development environment, review the repository's executable and instructional surfaces, and keep merge, deployment, and sensitive credentials behind independent controls.
Coding agents read code, documentation, issues, logs, and tool output, then may edit files or execute commands. A hostile repository can therefore influence both what the agent believes and what it runs. This guide explains a practical workflow for working on unfamiliar code without giving every file the authority of a trusted maintainer.
Recognize the repository as an input surface
A repository contains more than source code. README files, agent instruction files, comments, test fixtures, issue descriptions, generated logs, and dependency metadata can all reach the assistant. Some are useful project guidance; others may be supplied by an untrusted contributor or changed in the very branch being reviewed.
I would establish which instructions come from a trusted user or reviewed project configuration before treating them as authoritative. A file calling itself a security policy does not automatically grant permission to upload credentials or bypass review. Names and formatting can be imitated.
This is especially important for incoming pull requests. A contributor who can change files may also change instructions about how the agent should inspect those files. Keep the trusted task definition outside the unreviewed change and treat repository guidance as something to evaluate within that task.
Inspect the environment before running project commands
Before installing or testing unfamiliar code, review package scripts, build configuration, test commands, hooks, and relevant agent configuration. A command named “test” can run arbitrary project code. A routine installation can execute lifecycle scripts or load native components, depending on the ecosystem and configuration.
I would begin with read-only inspection and identify the smallest command needed for the task. Do not execute a command merely because an error message or repository document says it is required. Confirm its purpose and whether it introduces network access, elevated privileges, or changes outside the project.
Document legitimate prerequisites so later work is efficient, but do not convert one successful execution into blanket trust. Dependencies and scripts can change between branches. When the branch or package manifest changes, reassess the commands whose behavior depends on those files.
| Surface | What to inspect | Useful boundary |
|---|---|---|
| Repository guidance | Instruction and configuration changes | Trusted task outside unreviewed content |
| Install and test commands | Scripts, hooks, and dependencies | Restricted execution environment |
| Credentials | Environment and mounted files | Scoped or absent sensitive access |
| Final delivery | Diff, CI, merge, and release path | Independent review and repository policy |
Use isolation that the operating system enforces
A worktree or separate checkout helps organize edits, but it does not prevent a process from reading your home directory or contacting the network. Use a properly configured sandbox, container, or disposable virtual machine when running code from an untrusted source. The boundary must apply to the commands and tools the agent actually uses.
I would provide only the workspace mounts needed for the task. Avoid exposing host credential directories, broad SSH access, privileged container settings, or a host container-management socket. A container with powerful host mounts can undermine the isolation you intended to create.
Verify the environment rather than relying on a product label. Check which files, services, and network destinations are reachable. Keep the sandbox updated and understand its limitations. Isolation reduces consequences; it does not make malicious project code trustworthy or remove the need to review the resulting patch.
Keep credentials minimal and outside the task context
The agent rarely needs production credentials to fix a unit test or update documentation. Remove unnecessary environment variables and use synthetic configuration for local validation. A repository reader or shell can expose secrets that were never pasted into the chat, so examine the entire process environment and mounted filesystem.
For repository access, use a narrowly scoped credential or managed integration appropriate to the task. Read access may be enough for analysis; preparing a branch does not automatically require administrative rights, release credentials, or permission to change organization settings.
I would keep production deployment separate from ordinary coding sessions. If a later authorized step needs a secret, supply it through a controlled mechanism for that specific operation. Do not put reusable tokens into project instructions, test output, or a conversation as a shortcut for getting the agent unstuck.
The official Claude Code coding agent security explains its safeguards and responsibilities; check your installed version and configuration rather than assuming another tool behaves identically.
Constrain network access and dependency changes
A coding task may need documentation or package downloads, but unrestricted outbound access also creates a path for data to leave. Define the destinations needed for the workflow and enforce the policy at the network or execution layer where possible. A reminder in the prompt is not an equivalent boundary.
I would review new dependencies, registries, lockfile changes, and download commands. Confirm the exact package and source rather than trusting a similar-looking name suggested by a document. A troubleshooting instruction that fetches and immediately executes a remote script deserves more scrutiny than reading a known manual.
Be realistic about allowed registries: access to a shared package host is broader than approval of every package on it. Network restrictions complement package review and sandboxing. They do not independently prove that a permitted download is safe or that project scripts cannot misuse other available resources.
Understand the agent’s actual permission mode
Coding tools differ in what they can read, edit, execute, and approve automatically. Defaults can change between versions and surfaces. I would inspect the current permission and sandbox settings rather than relying on an old tutorial or assuming a familiar mode name means the same thing everywhere.
A permission prompt and an operating-system restriction are different controls. Once a broad command is approved, it may perform more than the reviewer expected unless execution is also constrained. Similarly, a directory-oriented editing rule may not restrict every path a shell process can access.
Prefer explicit limits for sensitive operations and avoid broad “allow everything” choices to reduce interruptions. If approvals become repetitive, improve the environment and narrowly defined task permissions. Removing all checks to make the workflow smoother can give hostile repository text exactly the authority it needs.
Review the patch independently of the agent’s summary
A coding agent's explanation can be incomplete or influenced by the same content that produced the change. Inspect the actual diff, including configuration, scripts, tests, dependencies, and newly created files. Confirm that the change matches the requested behavior and does not introduce unrelated network calls or privilege changes.
I would pay special attention to modifications that weaken validation or alter the evidence of success. Removing a failing assertion can make a test pass without fixing the bug. Changing a security-sensitive workflow may create risk even when the application code looks reasonable.
Use appropriate automated checks, but remember that project tests are executable code and may themselves be untrusted. Run them within the prepared environment. For important behavior, compare against requirements or trusted checks that were not silently rewritten by the same patch being evaluated.
For a related workflow issue, this guide to unexpected file changes explains how to distinguish necessary supporting edits from avoidable scope expansion. Scope control helps review; it does not replace execution isolation.
Keep merge, CI, and deployment behind separate controls
Preparing a patch should not automatically authorize merging it, publishing a package, or deploying to production. These steps carry different authority and can expose secrets or affect users. Maintain repository protections and review requirements appropriate to the project rather than letting an agent decide that passing tests is sufficient permission.
In continuous integration, be careful when untrusted contributions interact with privileged workflows or secrets. Review the event, token permissions, checkout behavior, and scripts that execute. Do not move unreviewed code into a privileged context merely to make a failing automation work.
I would let the agent produce a reviewable branch or patch, then use the normal trusted release process. When an authorized deployment is needed, review the concrete result and execution context. A general request to fix a bug should not silently become approval to alter production or publish credentials through build logs.
Test the workflow and recover from suspicious behavior
Use a disposable repository with harmless planted instructions to evaluate the setup. For example, a fixture can ask the agent to make an unrelated dummy change or contact a controlled destination. Verify whether the actual environment and permissions block the prohibited effect, not merely whether the agent claims to ignore the text.
If a real run attempts an unexpected operation, stop execution and inspect commands, changed files, network activity, and available credentials. Revoke or rotate exposed tokens when necessary. Recreate a compromised disposable environment rather than assuming a clean chat removes malicious files or processes.
My repeatable workflow is to inspect first, isolate execution, minimize secrets, constrain tools, and review the final diff through an independent process. This does not promise a perfectly obedient model. It gives a confused or manipulated agent fewer ways to turn an ordinary coding task into an account, repository, or production incident.
Common questions
Does a separate Git worktree prevent secret access?
No. A worktree separates working files, not operating-system privileges. Use real execution isolation and restrict mounts, credentials, and network access.
Are tests safe to run because they are tests?
No. Test runners and project scripts execute code. Inspect unfamiliar projects and run validation within the prepared restricted environment.
Should I trust every agent instruction file?
No. Establish its provenance and review it, particularly in untrusted branches or pull requests. A filename does not give its contents authority over your task.
Can I fix this with one agent setting?
No single setting covers repository trust, execution, credentials, network access, and delivery. Check the tool’s current behavior and combine appropriate controls for the workflow.