Shift Log: Shell Access Approved, Host Access Denied

Three shell policies entered the shift review

A coding agent that can run commands can inspect failures, execute tests, and repair code without asking you to copy terminal output. It can also delete files, expose credentials, or execute instructions planted in a repository. The operational question is not whether shell access is useful. It is which execution policy makes mistakes containable.

Compare three approaches: approve every command on the developer machine, allow unrestricted execution there, or grant bounded autonomy inside an isolated workspace. Judge them by interruption cost, potential damage, and recovery effort—not by how confidently the agent explains its next step.

Approval prompts beat blind execution, but lose on repetition

Manual approval gives engineers a checkpoint before execution. It fits unfamiliar repositories, occasional maintenance, and tasks involving privileged systems. You can reject a destructive command before it runs, provided the approval interface shows the actual command and its execution context.

The weakness is cumulative attention cost. Repeated prompts encourage mechanical acceptance. A harmless-looking test command may execute repository scripts, invoke package hooks, or load plugins. Approving the command text does not mean you have reviewed everything it triggers.

Unrestricted execution removes that friction, but on a normal workstation it also inherits too much ambient authority: readable credentials, mounted directories, network access, and whatever permissions the current user holds. Git cannot restore an uploaded secret or reverse a change to an external service.

The head-to-head verdict is manual approval over unrestricted host execution. Prompts are imperfect, but unrestricted access makes a misunderstanding or malicious instruction substantially harder to contain.

Bounded isolation beats prompts for routine iteration

An isolated workspace changes the decision from “Is this command safe?” to “What can any command in this environment reach?” That is a stronger foundation for repeated builds and tests. The agent can iterate without receiving the developer’s entire workstation as its operating environment.

A container can help, but the configuration determines the boundary. A container with the host container-engine socket, broad writable mounts, or privileged mode may expose the resources you meant to protect. A virtual machine may be preferable when the workload or threat model calls for stronger separation.

• Mount only the task workspace as writable, and keep unrelated host directories unavailable.
• Run as an unprivileged user without privileged mode or host management sockets.
• Remove inherited credentials and provide only narrowly scoped, short-lived credentials when necessary.
• Restrict outbound network access where practical, including access to internal services and cloud metadata endpoints.
• Set execution timeouts and resource limits, and retain command output for investigation.

The verdict favors bounded isolation for routine development. It reduces approval fatigue while limiting consequences. It does not prove generated code is correct or make untrusted dependencies safe.

Approval belongs at the authority boundary

Combine isolation with targeted approval rather than choosing between autonomy and supervision. Let ordinary compilation and tests run within the workspace. Require an explicit decision before expanding network access, injecting credentials, writing outside the workspace, or changing shared infrastructure.

Treat repository instructions, issue text, and command output as potentially untrusted input. A file telling the agent to upload environment variables is not authorization. Enforce restrictions in the execution layer; do not rely on a system prompt as the security boundary.

Before accepting the result, review the diff, check unexpected files, and rerun relevant tests in a trusted workflow. Keep deployment separate from code generation. A successful local test is evidence about behavior, not permission to release.

Model routing stays separate from shell permission

Relay365 fits when your team wants pay-as-you-go access to multiple model families while using tools such as Claude Code, Codex, Gemini CLI, or an OpenAI SDK. Its API base is https://api.api365relay.com; OpenAI clients add /v1. A model choice such as Gemini 2.5 Flash does not change the permissions its commands should receive.

If that routing flexibility matches your workflow, create a Relay365 account and evaluate it with a disposable repository first. Keep API credentials outside agent-readable files wherever your client architecture permits.

The handoff keeps host authority out of scope

The final verdict is bounded autonomy for daily work, targeted approval for boundary crossings, and no unrestricted shell on a credential-rich host. Start with disposable storage, minimal secrets, constrained networking, and reviewable output. The goal is not an agent that never errs; it is an execution environment where errors remain recoverable.