Your project stays your project.

Explore first. Approve deliberately.

Plan mode is read-only for project and external state. Work mode can prepare changes and run supported workflows, but every model-requested project change waits for an explicit Apply or Reject.

If implementation is requested during a Plan turn, Orca can ask once to switch modes. It waits for Stay in Plan or Switch to Work. That choice never serves as approval for a file change.

A proposal is not a write.

1. Orca captures bounded, request-scoped editor context.
2. It inspects the project information needed for the task through bounded tools.
3. In Work mode, it prepares an immutable proposal.
4. The proposal is validated and shown in a dedicated review card.
5. You choose Apply or Reject.
6. Apply rechecks the target, hashes, editor state, and validation before replacement.

File proposals are hash-bound and checked for stale or unsaved state. Applied proposals can be reverted while the in-memory checkpoint is valid and the target has not changed independently.

Bounded by design.

• Project access stays inside res://, rejects symbolic-link traversal, and excludes Orca’s own add-on directory from agent tools.
• Known unsaved scripts and scenes cannot be overwritten by proposals.
• Existing files require the exact SHA-256 returned by Orca’s file reader.
• Supported GDScript proposals are validated before review and immediately before writing.
• Tool rounds, searches, reads, responses, network inactivity, and owned game processes are bounded.
• Provider configuration is snapshotted for a turn so a tool loop cannot silently switch endpoint or model.

Know what is sent and stored.

Requests and endpoints

Prompts, relevant editor context, and project content returned by tools may be sent to the provider you select. A locally hosted endpoint may still forward received data elsewhere. Orca cannot verify what a server does after receiving your request.

Editable LAN and remote endpoints require confirmation for their exact scheme, host, and effective port. Orca identifies unencrypted non-loopback HTTP and does not follow provider chat or model-discovery redirects. Confirmation is informed consent, not proof of trustworthiness.

Local storage

API credentials are saved through Godot Editor Settings. Project conversation history is stored locally as plaintext JSON under Godot’s user:// storage. Neither is an encrypted operating-system credential vault.

Project guidance and diagnostics

Bounded root res://AGENTS.md instructions and project-skill catalog metadata, when present, are included in private request-scoped context. A selected skill body is sent only after an explicit skill-loading tool call. Temporary guidance is removed from resumable history after the turn.

The About page can copy an allowlisted diagnostic report containing versions and coarse provider/request state. It excludes credentials, endpoint addresses, model IDs, project paths and content, conversations, model output, logs, process output, changes, and hashes.

Clear limits. Better expectations.

• Orca 1.2.1 supports Godot 4.7.2. Broader compatibility is not currently claimed.
• Runtime verification evaluates narrow startup or exit criteria from bounded process output. It cannot prove visual or gameplay correctness.
• Pending approvals and revert checkpoints do not survive an editor or plugin restart.
• Structured scene operations support a constrained set of nodes, values, dependencies, and signals.
• Script attach and detach require a separate Trust and Prepare decision because Godot may execute project code while constructing a candidate. This is informed consent, not sandboxing.

For complete details, read SECURITY.md and DEVELOPMENT.md.