Key facts
| Access pattern | Search, read and targeted edit tools over the working tree rather than whole-tree prompts |
| Context selection | Relevant files are chosen by search and dependency tracing, not by directory size |
| Change control | Diffs proposed and reviewed before writes; work stays on a scratch branch |
| Sandboxing | Allow-listed commands in an isolated environment with timeouts |
| Secret handling | Exclude .env, credentials and build artifacts from agent-visible paths |
| Model choice | Coding aliases for edits, long-context aliases for repo-wide questions; 30+ models available |
| Status | Function calling, streaming and agents are live |
| Deployment | Cloud, VPC, on-prem and air-gapped options for restricted repositories |
TL;DR
- Give the agent tools — search, read, edit, run — not a directory dump.
- Scope access to one repository and exclude secrets by default.
- Require reviewable diffs on a scratch branch before anything merges.
- Sandbox commands and cap loop iterations.
- Drive the loop with tests so failures become the next instruction.
How it works, step by step
- Clone the repository to a working copy and create a dedicated branch for the agent.
- Add ignore rules for .env files, credentials, node_modules and build output.
- Expose the agent's toolset: list, search, read, write, patch and run tests — nothing broader.
- Start with a scoped task backed by a failing test or an exact issue description.
- Review each diff and run the test suite before accepting the next iteration.
- Log the session and reset the branch if the agent drifts off scope.
Try it yourself
Open the agent workflow designer →
How local file access should work
The agent needs a small set of well-defined tools: list a directory, search for a symbol or pattern, read a file range, write a patch, run a test command. Each call is explicit and logged. This design keeps prompts small, makes the agent's reasoning auditable, and means the model never sees files it does not need. Whole-tree prompting is the common anti-pattern: it inflates cost, slows every turn and buries the relevant lines in noise.
Scoping access safely
- Operate on a dedicated clone or worktree so the agent cannot touch your main checkout.
- Exclude secrets, keys, production configs and build artifacts from all agent-readable paths.
- Restrict writes to the repository root and forbid paths outside it.
- Allow-list commands — tests, linters, formatters — instead of granting an unrestricted shell.
- Run in a container when the codebase or dependencies are untrusted.
These controls matter more when the agent reads untrusted input such as issues or pull request comments.
A test-driven agent loop
Give the agent a concrete signal to optimize: a failing test, a reproduction script or a precise acceptance criterion. The loop becomes read context, propose a diff, run the suite, inspect failures, revise. Because the test is local and fast, each iteration is cheap and verifiable. For larger changes, ask the agent to write the test first, then iterate until it passes without weakening assertions.
What to review before merging
- Diff scope: only the requested change, no unrelated refactors.
- Test quality: assertions strengthened, not deleted, to make the suite pass.
- Dependency changes: new packages justified and pinned.
- Error handling: failure paths still covered.
- Session log: prompts and commands consistent with the task.
Keeping the branch small makes this review minutes, not hours — which is the whole point of using an agent.
Honest comparison
| Approach | Context cost | Safety | Review effort |
|---|---|---|---|
| Tool-based file access | Low — reads only what is needed | High — scoped tools and logs | Low — small diffs |
| Whole-tree prompting | High every turn | Low — everything exposed | High — noisy changes |
| Copy-paste into chat | Medium | Medium — you choose files | Medium — manual re-apply |
| Agent with unrestricted shell | Low | Very low — destructive risk | High — hard to audit |
Frequently asked questions
Should I give an agent access to my whole repository?
No. Give it search, read and patch tools with writes scoped to a working copy. On-demand reads keep prompts small and make the agent's behavior auditable.
How do I stop an agent from reading secrets?
Ignore rules plus path restrictions on the agent's file tools. Never rely on asking the model to avoid .env files — enforce it in the tooling layer.
What is the safest way to let an agent run commands?
Allow-list the commands it needs, run them in a container with timeouts, and require confirmation for anything outside the list.
Does Plugsky work with local coding agents?
Yes. Plugsky's OpenAI-compatible API works with agents that accept a custom base URL, so local file tooling stays on your machine while inference runs against Plugsky's live endpoints.
How large a task should I give a coding agent?
One reviewable change at a time, backed by a test. Small scoped tasks produce smaller diffs and fewer regressions than broad refactors.
Can this run in an air-gapped environment?
Yes. Plugsky supports VPC, on-prem and air-gapped deployments, so the model endpoint can live inside a network with no public internet access.