DSHGuide

Contents / Chapter 4

Chapter 4 — Workspaces, Files, and Permissions

4 min read · 850 words · 12 sections

What You Will Learn

  • Why the workspace is a safety boundary;
  • What the Agent can read and write;
  • The difference between workspace-write and danger-full-access;
  • How to avoid deletion, overwriting, and secret leaks;
  • How to use AGENTS.md to set project rules.

4.1 What a Workspace Really Is

A workspace is a folder.[1]

The Agent's current directory is usually that folder. When you say "read notes/a.md", it looks for notes/a.md inside the workspace.

A workspace does three jobs:

  1. Scope: the Agent works here by default;
  2. Context: files and instructions here shape its decisions;
  3. Permission boundary: many safety policies are scoped to it.

So a workspace is not "just any folder". It is the boundary you draw around the Agent's work.

Recommendations

  • One project, one workspace;
  • Do not include your entire home directory;
  • Use git init for important projects;
  • Use a scratch folder such as dsh-test for experiments.

4.2 What the Agent Can Read and Write

The Agent acts through tools:

Tool What it does Risk
Read file View content Low, but it may read sensitive data
List/search Find files Low
Write file Create or overwrite High: may overwrite originals
Edit file Replace a section Medium: may edit the wrong place
Run command Execute programs Very high: delete, reset, upload

Reading is not automatically safe. If the workspace contains .env, keys, or customer data, the Agent may read it, put it into context, or repeat it.

Least privilege

  • Give it only the folder needed for the task;
  • Do not hand it your whole home or repository root;
  • For sensitive data, redact or copy into an isolated folder first.

4.3 Two Common Permission Modes

workspace-write

  • Read and write inside the workspace;
  • Outside the workspace, usually read-only or approval-required;
  • The right default for most daily tasks.

danger-full-access

  • Broader access;
  • Higher-risk operations;
  • Use only when you know exactly what you are doing, such as installing plugins or system-level debugging.

Do not leave full access on just because it is convenient. More permission means a larger blast radius.

Approval prompts

When the Agent wants a sensitive action, DSH may ask:

Allow this operation?

You can:

  • Allow once;
  • Deny;
  • Stop the task.

When you see delete, overwrite, reset, push, upload, or install, read the details before clicking.

4.4 Destructive Operations: Back Up First

Possible dangerous actions:

  • Delete files or directories;
  • Overwrite existing files;
  • git reset --hard;
  • git push --force;
  • Modify system configuration;
  • Install or uninstall software;
  • Upload files to an external service.

Three rules

  1. Back up important files;
  2. Use git when possible: commit before the Agent changes things;
  3. Ask for the impact and rollback plan before approving.
Before deleting or overwriting anything, list the affected files and tell me how to roll back.
Do not execute until I confirm.

Git is your undo button

git add -A
git commit -m "before agent changes"

If the Agent breaks something:[2]

git diff
git restore .

Do not let an Agent make broad changes to important files without version control.

4.5 Secrets, Passwords, and Screenshots

This is where most accidents happen.

Do not

  • Paste API keys, passwords, or tokens into chat;
  • Copy .env contents to the Agent;
  • Let it upload files containing secrets;
  • Show it screenshots containing keys.

Do

  • Keep secrets in environment variables or a secret manager;
  • Let the Agent change variable names, not values;
  • Show redacted examples;
  • If a secret was exposed, stop and rotate it.

The Agent's context may be logged, replayed, or displayed. Treat anything pasted into chat as leaked.

4.6 AGENTS.md: Project Rules

AGENTS.md is a project instruction file. The Agent reads it and tries to follow it.

Example:

# Project Rules

- Reply in English.
- Do not modify `dist/` or `node_modules/`.
- Read related files before changing code.
- Run `pnpm test` before committing.
- Ask me before deleting any file.
- Do not read `.env`.

Use it for:

  • Code style;
  • Directory rules;
  • Forbidden actions;
  • Test commands;
  • Delivery format;
  • Team conventions.

AGENTS.md is guidance, not a hard sandbox. It reduces mistakes but does not replace permission controls.

4.7 Workspace Hygiene

  • One task per folder;
  • Keep inputs, outputs, and temporary files separate;
  • Delete temporary files when done;
  • Do not mix test data with personal data;
  • Confirm before reading very large files.

Try It

  1. Create a dsh-test workspace;
  2. Add an AGENTS.md with three rules;
  3. Ask the Agent to read it and repeat what it will follow;
  4. Ask it to modify a file and observe the approval prompt;
  5. Deny once and see whether it stops.

Common Pitfalls

  • Workspace too broad: larger blast radius.
  • Permanent full access: risk accumulates.
  • No backup before delete/change: no rollback.
  • Pasting keys into chat: immediate leak.
  • Treating AGENTS.md as a sandbox: it is guidance only.

Summary

  • Workspace = scope + context + permission boundary.
  • Reading can be risky; keep secrets out of chat.
  • workspace-write is the daily default; danger-full-access requires restraint.
  • Back up and confirm before destructive operations.
  • AGENTS.md sets rules but does not enforce them by itself.

References

  1. DeepSeek Harness GitHub repository
  2. Git documentation

All links are public sources; product behavior may change between versions.

↑