Is DAO-Code Automatic Execution Safe? 2026 Team Mode Selection Guide

The official DAO-Code README names five execution approaches: plan, default, acceptEdits, auto, and bypassPermissions (the project README). That is the useful starting fact: your team should use item-by-item approval by default. Choose plan for read-only work. Move to auto only after directory isolation, secret protection, rollback, and audit tests pass. Keep bypassPermissions out of normal team development.

This week, set the baseline to default approval, create a disposable test workspace, and run the boundary tests below before granting anyone automatic execution.

This guide is for:

• Technical leads defining a DAO-Code team policy.
• Security engineers protecting repositories, API keys, SSH settings, and build credentials.
• Platform administrators preparing repeatable DAO-Code environments for multiple developers.

DAO-Code automatic execution: start with the risk ceiling

Automatic execution improves speed. It does not remove responsibility. A mode controls how much approval is required, but it does not prove that every command, plugin, hook, MCP service, or external input is safe.

Treat the mode as a risk ceiling, not as a security certification.

The project’s published security material describes execution modes, layered rules, sensitive-target confirmation, audit logging, and an optional system sandbox (the DAO-Code security policy). Those are project features and design claims. They are not a third-party security certification. They also do not establish that every extension, hook, or MCP integration is safe.

Use this decision order:

• If the repository is unfamiliar or the task only needs inspection, choose plan.
• If the repository is trusted but changes and commands need review, choose default or another item-by-item approval workflow.
• If the task is bounded, the workspace is isolated, and recovery has been tested, evaluate auto.
• If the task involves production credentials, irreversible actions, or unreviewed external tools, return to manual approval.
• If the environment cannot be destroyed quickly, do not use bypassPermissions.

Security reminder: “Automatic” describes the approval flow. It does not describe the trustworthiness of the generated code, shell command, dependency, MCP server, or external data source.

The mode comparison: control versus throughput

The important comparison is not “slow mode versus fast mode.” It is visible decisions versus delegated decisions. Your team should decide which actions require a human gate before selecting a mode.

The exact behavior still depends on the configured rules and the project version. Confirm the current names and priority in the README and security policy before publishing an internal standard.

A productive approval gate should be narrow. You do not need a person to approve every harmless read. You do need a person to approve access to sensitive paths, external network actions, credential-bearing commands, destructive operations, and changes outside the assigned workspace.

First step: define the action classes

Write the policy in action classes, not vague labels such as “safe command” or “trusted agent.”

Allow after review:

• Reading files inside the assigned repository.
• Editing files inside the assigned worktree.
• Running deterministic tests with no external credentials.
• Creating temporary build output inside the workspace.

Ask every time:

• Writing outside the assigned directory.
• Reading SSH configuration, cloud credentials, API key files, or keychain-backed values.
• Sending data to an external endpoint.
• Installing dependencies or changing system-wide tools.
• Running destructive commands or commands with irreversible effects.

Deny by rule:

• Direct access to production secret stores.
• Unapproved parent and sibling directories.
• Credential export or bulk environment dumps.
• Network calls to destinations outside the task boundary.
• Hooks, MCP tools, or plugins that have not passed team review.

This classification also helps you audit a rule set. If a policy cannot clearly say whether an action is allowed, it is not ready for auto.

Files, shell commands, and directory boundaries

File editing and shell execution have different failure modes. A file rule may block a direct edit while a shell command still copies, archives, prints, or uploads the same content. Review both paths.

Your acceptance test should cover at least these cases:

1. Ask DAO-Code to edit a harmless file inside the worktree.
2. Ask it to write a harmless marker file in a sibling directory.
3. Ask it to read a deliberately fake secret outside the worktree.
4. Ask it to run a command that enumerates environment variables.
5. Ask it to access an external endpoint through a tool or subprocess.
6. Repeat the out-of-scope write in the intended automatic mode.
7. Confirm that the event appears in the audit record.

The second and sixth tests matter most. A deny rule that works only during an interactive prompt is not enough. You need to know whether the deny rule still wins when the agent runs automatically.

Use a throwaway path for these tests. Do not place real credentials in the fixture. Do not use production repositories as a test target.

The word shadow-git should also be treated as a recovery feature to verify, not a promise of complete rollback. Check whether it creates a usable checkpoint, which files it includes, and whether the restore operation changes the project’s official Git history. Your team should be able to discard the test state without rewriting shared branches or deleting a reviewer’s work.

Credentials and external connections: the hidden approval boundary

A repository can be trusted while its runtime environment is not. A local process may inherit environment variables. A child process may receive more access than the visible command suggests. A log may capture a command line, an error response, or a tool argument containing sensitive material.

Build a credential inventory before enabling automatic execution:

The project’s security policy may describe sensitive-target confirmation and secret-related protections. Verify the behavior in your own environment. A feature declaration is not the same as a completed security audit.

Use system keychain options where available, but do not assume that storing a secret securely prevents an agent from using it. The question is different: can the agent retrieve, print, transmit, or pass the secret to another process without an approval gate?

The general agent-security guidance recommends limiting tool privileges, validating external input, separating trusted and untrusted content, and controlling outbound actions (the AI agent security guidance). Apply those principles to MCP tools and hooks as well. An MCP server expands the execution boundary even when the main repository is clean.

Test with fake values first: Put a recognizable dummy token in a disposable fixture, then check prompts, logs, child-process output, audit files, and generated artifacts. Never use a live production key to prove that secret masking works.

macOS Seatbelt and workspace isolation

A system sandbox can reduce the blast radius, but it cannot repair a badly scoped policy. The sandbox must be configured for the task, tested against the actual process tree, and reviewed after tool changes.

On macOS, review the documented sandbox model and its file and network implications (the macOS app sandbox documentation). Do not infer that a sandbox automatically covers every helper process, terminal command, container, or remote service.

For a DAO-Code environment, separate these layers:

• Repository boundary: The agent’s assigned worktree.
• Process boundary: Shells, package managers, test runners, hooks, and child processes.
• Credential boundary: Keychain access, environment variables, config files, and mounted secrets.
• Network boundary: Package registries, APIs, MCP endpoints, and arbitrary outbound destinations.
• Recovery boundary: Shadow checkpoints and the project’s normal Git history.

A useful rollout condition is simple:

If the agent can write outside the workspace, access a real credential, or reach an unapproved endpoint during testing, do not enable auto.

You can link your internal environment procedures to the Hashvps help center when preparing operator documentation. Keep the security policy itself in your repository or team control system so changes receive review.

Recovery: compare approval cost with rollback cost

Manual approval slows a task before the action. Weak recovery slows the team after the action. The correct choice depends on which delay is more expensive for your repository.

For each test run, record:

• The initial commit or clean worktree state.
• The files intentionally changed.
• The commands executed.
• The generated artifacts.
• The shadow-git checkpoint identifier, if available.
• The restore command used.
• The final difference from the initial state.
• Whether official Git history changed.

Then test three recovery paths:

• Restore from the project’s normal Git state.
• Restore from the DAO-Code shadow checkpoint.
• Destroy and recreate the isolated workspace.

A recovery path is not proven until you inspect the result. “The command completed” is not evidence that untracked files, ignored files, generated output, or external side effects were removed.

This is where auto often fails as a team default. It may reduce approval interruptions while increasing the amount of work required to identify and reverse a bad change. For a disposable test task, that trade may be acceptable. For a shared repository, it usually is not.

Audit records must support responsibility

An audit log should answer four questions:

• What action was requested?
• Which rule or approval decision allowed it?
• Which identity or session initiated it?
• What changed after the action?

Check whether the record includes file writes, shell commands, network actions, denied operations, mode changes, and tool calls. Also inspect what the record does not include. A log can be detailed enough to investigate a failure while still omitting the actual secret value.

Follow the project’s audit features, then apply general secure-logging principles: avoid secrets, tokens, unnecessary personal data, and raw sensitive payloads (the secure logging guidance). Give logs a retention and access policy. An audit file that every developer can edit is evidence with limited value.

Assign ownership before rollout:

• The technical lead approves the mode for each task class.
• The security engineer reviews rules, credentials, and audit output.
• The platform administrator maintains the image, sandbox, and reset process.
• The code owner reviews changes made by the agent.
• The incident owner handles a boundary failure or secret exposure.

A DevSecOps reference model can help map these responsibilities across development, verification, deployment, and feedback loops (the DevSecOps reference model).

Decision conditions for a team rollout

Use these conditions as your approval gate. Select the first branch that matches the task.

• If the repository is unfamiliar, the input is untrusted, or the task is analysis-only, choose plan. Do not grant write access just to make exploration faster.
• If the repository is trusted but shared, choose item-by-item approval. This is the default for normal development, code review preparation, and dependency changes.
• If the task has a fixed directory, no production credentials, tested deny rules, tested recovery, and reviewed tools, then evaluate auto in an isolated workspace. Record the test evidence before granting access.
• If the task can touch SSH settings, cloud credentials, production data, irreversible commands, or unreviewed MCP tools, keep human approval enabled. A trusted repository does not make these operations low risk.
• If the environment cannot be reset without affecting official Git history, do not use automatic execution. Fix the recovery process first.
• If the only reason for bypassPermissions is convenience, reject it. Use a smaller workspace or a narrower task instead.
• If the environment contains no credentials and can be destroyed immediately after testing, a bypass-style workflow may be acceptable for a short experiment. It is still not a team-wide production baseline.

For teams delivering repeatable environments, document the mode, rules, credentials policy, sandbox settings, reset procedure, and evidence location together. A mode selected in a chat message is not a durable control.

FAQ

Is a DAO-Code automatic execution command safe by default?

No execution command should be treated as safe merely because it runs inside a repository. DAO-Code documents several permission modes, but the actual risk depends on repository trust, rule priority, credentials, external tools, and sandbox settings. Start with plan or item-by-item approval, then test denied paths, secret handling, rollback, and audit records before expanding automation.

Which DAO-Code mode should a team use?

Use plan for unfamiliar repositories, code review, and read-only analysis. Use the default approval workflow for normal development because each consequential action remains visible. Consider auto only for a bounded workspace after isolation and recovery tests pass. Keep bypass-style execution out of routine team work and reserve it for disposable, credential-free experiments.

What must be checked before enabling DAO-Code auto mode?

Verify the workspace boundary, deny rules, approval gate behavior, secret exposure, child-process environment, external network access, shadow-git checkpoints, and audit records. Run a deliberate out-of-scope write test and a fake-secret test. Confirm that recovery restores only the test state and does not rewrite the team’s official Git history.

Is DAO-Code yolo mode suitable for a production project?

No. A bypass-style or yolo workflow is not a suitable default for production code, production credentials, irreversible commands, or unreviewed MCP tools. Even if the workspace is trusted, the agent may invoke a plugin, hook, subprocess, or external input with different risk characteristics. Use manual approval whenever the blast radius cannot be quickly destroyed.

How can you restrict DAO-Code to the working directory?

Combine path rules with an isolated workspace and a negative test. Allow the project directory, deny sensitive parent and sibling paths, then ask DAO-Code to create a harmless file outside the workspace. Repeat the test in automatic mode. Do not rely on a rule name alone; confirm the effective priority, process permissions, sandbox behavior, and audit evidence.

The final choice: control the boundary before buying speed

For most teams, the default approval workflow is the right baseline. plan is the safer choice for unfamiliar code and read-only analysis. auto belongs in a tested, bounded environment. bypassPermissions belongs only in disposable experiments without credentials or durable data.

A local Mac can be perfectly adequate when you can provide a separate worktree, clean credentials, a tested sandbox, and a reliable reset process. The weak points are usually operational: shared user accounts, mixed project files, long-lived secrets, unclear ownership, and no independent recovery environment.

If your current setup cannot provide an isolated workspace, repeatable reset, or controlled credential boundary, renting a dedicated Mac environment from Hashvps can be easier to govern than sharing one developer machine. The important benefit is not automatic execution by itself. It is having a disposable environment where you can test directory denial, fake-secret handling, audit records, and recovery before the workflow reaches a shared repository. Review the available Hashvps environment options only after the team has written its approval policy and acceptance tests.