Ignoring Files

A .multiignore file tells Multi which paths it should leave alone. When Multi tries to open or modify a matching path, the request is blocked and the agent is steered away from it.

Location and syntax

Place a .multiignore file in your project root. It uses the same syntax as .gitignore:

# secrets and credentials
.env
.env.*
secrets/
**/*.pem

# infra and keys
deploy/keys/
config/production.json

Patterns are matched relative to the directory containing the .multiignore file.

What it does

Reading and editing a matched path is blocked, and Multi is told to avoid it. This is useful for keeping Multi’s attention away from secrets, credentials, and other files it has no reason to touch.

It is not a security boundary

.multiignore is a guardrail, not a sandbox. It steers the agent away from sensitive paths, but it does not physically prevent access:

• It reduces the chance of accidental exposure, but a model can still work around the guidance - for example by reaching a file indirectly through a shell command.
• It relies on the agent following instructions rather than a hard system-level restriction.

If you need real protection, don’t rely on .multiignore alone. Combine it with actual isolation, for example:

• Run Multi inside a sandbox, container, or VM without access to the secrets.
• Keep credentials outside the workspace entirely (environment injection, secret managers).
• Use OS-level file permissions to deny read access.
• Require approval for commands so risky access is caught before it runs.

Treat .multiignore as a hint that lowers noise and accidents, and layer real sandboxing on top when the data actually matters.