Permissions and safety

Explyt can read and change files, run terminal commands and IDE configurations. Before a task, decide what data the agent may see, what it may change, and which actions it may perform. These restrictions come from different mechanisms: there is no single switch that covers every kind of access.

Reading files

Inside the project, the agent can read code, tests, resources and configurations. Edit Scope does not restrict reading: it defines the editing area only.

.explyt/tools/.readignore forbids the agent to read the listed files and folders. .explyt/tools/.writeignore separately forbids writing and creating files under the listed paths. To close a path for both reading and writing, add it to both files. The rules use gitignore-like patterns, but support for the entire .gitignore syntax is not guaranteed. This suits files with API keys and other data that must not reach the agent's context.

By default, access outside the project is limited to the project root and Explyt's service paths: the local Maven and Gradle caches, the log, scratch and temporary IDE file directories, the system temporary directory and the agent's home directory. For a project in WSL, its /tmp directory is allowed as well.

Unrestricted file reading

The Allow unrestricted read access to file system setting in Settings → Tools → Explyt → Agent → File Access lets the agent read files anywhere on the local file system. You need it, for example, when a task requires studying the sources of an external SDK, a shared configuration file or a neighboring repository that lies outside the project and the allowed service directories.

1. Open Settings → Tools → Explyt → Agent → File Access.
2. Enable Allow unrestricted read access to file system.
3. Run the task that needs the external file.
4. Turn the setting off afterwards if you do not need permanent access.

Risk: the agent will be able to read any local file available to the current user, including documents, keys and configurations with secrets. The setting removes the restriction on file location; keep using .readignore to explicitly block sensitive paths.

For details, see .readignore and .writeignore.

Writing and the scope of changes

There are two independent restrictions:

• Edit Scope lets the agent propose and apply edits only in the files and folders selected for the current task. The rest of the project remains readable.
• .explyt/tools/.writeignore forbids writing and creating files under the listed paths, but leaves them readable.

Edit Scope and .writeignore solve different problems. The first defines the working area for a specific task, the second forbids writing under the listed paths across the whole project. For sensitive data, add the path to both .readignore and .writeignore.

Asking in plain text "don't change these files" describes an intention, but it does not configure Edit Scope or the ignore files. For a task with a narrow area, set Edit Scope, and keep permanent bans in the ignore files.

Unrestricted file writing

The Allow unrestricted write access to file system setting lets the agent create and change files anywhere on the local file system. You only need it for a task that genuinely has to change an external file: for example, to update a shared configuration file or make coordinated edits in a neighboring repository.

1. First enable Allow unrestricted read access to file system: without it the write setting is unavailable.
2. Enable Allow unrestricted write access to file system.
3. Before running the task, set permanent bans in .writeignore and the current editing area in Edit Scope, if external files are added to it.
4. Review the diff or the contents of every changed external file.
5. Turn unrestricted writing off after the task. If you turn off unrestricted reading, Explyt turns off unrestricted writing automatically.

Risk: the agent will be able to overwrite or create any file available to the current user, including files of other projects and user configurations. Such a change may not show up in the regular diff of the current repository and may corrupt data. Enable the setting only for the duration of a specific task; for a single external file it is safer to move it into the project or make the edit by hand.

Commands and IDE configurations

The agent can run terminal commands. In the Tools menu you can allow or forbid individual tools, or require a confirmation before a call. Before working with an unfamiliar project, review these settings and forbid any runs you do not need.

For tests, builds and applications, IDE configurations are preferable. The agent uses the already configured SDK and gets a structured run result. Using an IDE configuration does not make an action harmless in itself: an application or a test can change a database, files or external systems. Check which configuration will run and in which environment.

Confirmations

Keep two kinds of control apart:

1. Before the action, restrict access through Edit Scope, the ignore files and tool permissions.
2. After the change, review the diff and the run results.

Confirmation is configured per tool in the Tools menu, not with one switch for all actions. If an action is dangerous or irreversible, enable confirmation or forbid the corresponding tool. Do not give the agent access to production environments without the controls your team has agreed on.

Reviewing and rolling back changes

Agent Changes shows the files changed in the active chat and the diff for each file. In this window you can accept or reject individual edits, and also process several changes at once. Changes from different chats do not mix.

Review edits before committing:

1. Look through every changed file and make sure the edits belong to the task.
2. Reject unnecessary changes in Agent Changes.
3. Run the relevant tests or a build through an IDE configuration.
4. Check the run result, not just the agent's text report.

Agent Changes covers the agent's file edits. The documentation does not guarantee automatic rollback of the consequences of an executed command, a migration, a request to an external system or an application run. For such actions, prepare a test environment, backups and your project's standard rollback procedure in advance.

Minimal setup for your first task

For a safe introduction, start with a read-only task:

• pick a small file with no secrets;
• ask the agent not to change or run anything;
• verify the explanation using IDE navigation;
• make sure Agent Changes is empty.

A step-by-step scenario is available in the Quickstart.