Use Agents safely

Agent risk comes from turning model suggestions into real actions. The objective of safe use is not to block every action, but to keep the scope of each action clear, its authorization explicit, and its result verifiable.

Start with Default permissions

Default permissions allow work inside the workspace and ask before important actions such as commands or file changes. Consider Full access only when a task genuinely needs files outside the workspace, automatic execution of high-impact commands, or fewer approvals.

Custom permissions are useful when you need to separate reads, writes, commands, and file modifications explicitly. Note that changing specific Custom settings does not automatically update permission snapshots in saved Scheduled Automations.

A five-step approval-card check

1. Source: Is the action from a foundational Tool, a Skill, an external MCP Server, or a browser capability?
2. Target: Are the path, command, server, website, and project correct?
3. Scope: Is it broader than the task requires?
4. Reversibility: Can Git, a backup, or external history restore it?
5. Evidence: How will you confirm the actual result afterward?

The model's stated reason for a call can help you understand it, but cannot replace your judgment.

Protect credentials and sensitive data

• Do not put tokens or passwords in prompts, project files, MCP argv, screenshots, or test fixtures.
• Model requests are sent to the configured API URL, and search queries are sent to Tavily.
• A local MCP Server is an independent process that may access the computer or network. Review it as third-party software.
• Webpages, project documentation, and MCP tool descriptions may contain text designed to persuade the model to exceed its authority. Treat all of them as untrusted input.
• Remove paths, accounts, queries, and business data before sharing logs or screenshots externally.

Signed macOS releases store the model Token and Tavily Key in the system keychain, while SQLite retains only opaque references. The application never redisplays stored values. Enter a new value to replace a credential, and re-enter credentials after importing configuration. Protecting the operating-system account, keychain, disk, and application data directory remains important.

Add safeguards for destructive or external actions

• Perform a read-only preflight before writing.
• Require an exact target; do not accept vague whole-disk scans or bulk deletion.
• Commit or back up important projects first.
• Review package management, network upload, release, payment, and messaging actions separately.
• Do not permanently expand permissions merely to remove one approval prompt.

Handle “Outcome unknown” correctly

An unknown outcome means the action may already have happened. In this state:

1. Do not repeat the call immediately.
2. Check the actual state of the files, process, webpage, or external system.
3. If the action succeeded, update only the local record.
4. If it failed, retry with a new, explicit action.
5. If you cannot determine the result, preserve the uncertainty and request human handling.

Additional precautions for Scheduled Automation

• It does not run in the background after the application exits.
• A background task may still wait for approval.
• The prompt should be self-contained instead of relying on temporary chat context.
• Use the lowest required permissions, and regularly inspect Run history and needs-attention items.
• Do not use it for critical work that cannot tolerate missed runs, merged recovery, or notification delays.

Read the wording before deleting or removing

Remove project deletes that project's local conversations, messages, and attachment records from Captain Who, but does not modify the project's source directory. Deleting a Scheduled Automation does not delete chats created by earlier runs. Different delete actions have different scopes; do not infer their effects from the button label alone.

For more current boundaries, see Capability limits.