MiraBridge Desktop is designed around explicit human control. The agent can ask to inspect files, edit files, run terminal commands, operate git, or use runtime tools, but sensitive actions are surfaced for approval before execution.
Approval States
A Desktop tool request can take one of three paths:
| Path | Behavior | | ---- | -------- | | Pre-approved | The Gateway marks the request as already approved and Desktop executes it immediately | | Desktop approval | Desktop waits for the approval session, then executes or rejects based on the user decision | | Local auto-approve | Desktop may auto-approve narrow read-only workspace tools based on local policy |
Read-only tools are good candidates for automation. File writes, terminal commands, git mutations, and destructive operations should remain approval-gated.
What an Approval Shows
Approval cards are intended to make execution inspectable:
- Tool name
- Command or operation arguments
- Target workspace
- Affected path or working directory
- Execution status
- Result, error, or command output after completion
For terminal commands, review the exact command and working directory before approving.
Workspace Boundary
Desktop resolves local file paths and command working directories against the selected workspace. Requests outside that workspace are refused.
Examples:
| Request | Result |
| ------- | ------ |
| read_file with src/app.ts | Allowed if the file exists in the workspace |
| run_command with cwd: "apps/website" | Allowed if that directory exists in the workspace |
| run_command with cwd: "../other-project" | Refused |
| File write into .ssh or common secret paths | Refused |
Sensitive File Protection
Desktop avoids exposing common secret-bearing paths and files to the agent. This includes .env variants, private key files, package registry credentials, cloud credential folders, git config, and paths that look like secrets, passwords, or tokens.
This protection is defense-in-depth. You should still keep secrets out of prompts, commits, screenshots, and command output.
Command Guardrails
Desktop command execution includes additional guardrails:
- Commands run only after approval unless policy says otherwise.
- Commands run inside the selected workspace.
- Dangerous command substrings are denied.
- Sensitive environment variables are removed before process launch.
- stdout and stderr are capped.
- Commands have default and maximum timeouts.
- Running commands can be cancelled.
Git Operations
Desktop supports status, diff, add, commit, pull, and push operations. Treat git mutation approvals carefully:
| Operation | Recommended review |
| --------- | ------------------ |
| git_status | Safe to inspect freely |
| git_diff | Review before any commit |
| git_add | Confirm the selected files |
| git_commit | Confirm the message and included files |
| git_pull | Confirm branch and merge/rebase behavior |
| git_push | Confirm remote, branch, and whether upstream flags are used |
Mobile Approval
Mobile can approve Desktop-routed work through the shared Gateway. The execution still happens on Desktop against the Desktop-selected workspace.
Use mobile approval when you are away from the machine but still want to supervise the agent. Reject anything that is unclear, broad, or surprising.
Best Practices
- Start new repositories with read-only prompts.
- Ask the agent to explain a terminal command before running it.
- Prefer focused test/build commands over broad scripts.
- Keep destructive commands manual.
- Review diffs before approving commits.
- Reject requests that target unexpected paths or branches.
- Use separate workspaces for unrelated projects.
Next Steps
- Terminal Commands - command execution details
- Security Overview - platform-wide security model