Protecting Your Project: Filesystem Safety and Approvals

Project Boundary Enforcement

Estimated reading: 0 minutes 8 views

GameCatalyst ensures the AI can only access files within your Unity project directory. It cannot read, modify, or delete anything outside the project root. This protects the rest of your computer from accidental changes.

How it works:

When you select a project, GameCatalyst records the root directory (the folder with Assets, ProjectSettings, Packages). Every file operation is validated against this path. If the AI tries to access something outside, the command fails: Error: Path is outside the project root. Access denied.

Inside the project (allowed):

C:/Projects/MyGame/Assets/Scripts/Player.cs
C:/Projects/MyGame/CustomFolder/data.json

Outside the project (blocked):

C:/Projects/OtherGame/Assets/Enemy.cs — different project
C:/Users/Alex/Desktop/file.txt — outside projects
C:/Windows/System32/important.dll — system files

Relative paths: If the AI uses Assets/Scripts/Player.cs, GameCatalyst resolves it relative to the project root. Path traversal attacks like ../../etc/passwd are caught and blocked. Symbolic links are resolved to their real locations first.

Configuration: The deny_outside_project setting defaults to true. Leave it enabled — turning it off would let the AI access files anywhere on your machine.

Why this matters: Without boundaries, a path typo could lead to modifying files in a different project or even system files. Project containment eliminates that risk. Your project is a sandbox.

Relative path resolution:

If the AI uses a relative path like Assets/Scripts/Player.cs, GameCatalyst automatically resolves it relative to the project root. This prevents path traversal attacks like ../../etc/passwd from escaping the project boundary. Symbolic links and directory junctions are resolved to their real locations before the boundary check runs, closing another potential escape route.

Configuration:

The deny_outside_project setting in gamecatalyst-config.json controls boundary enforcement. It defaults to true and should stay enabled. Turning it off would allow the AI to access files anywhere on your machine, defeating the purpose of project isolation entirely.

Combined with other safety layers:

Project boundary enforcement works alongside protected paths (.git, Library, Temp, Logs are always blocked even inside the project), dry-run mode (file writes preview before executing), and permission gates (commands must be enabled to run). These layers reinforce each other so no single misconfiguration compromises your project’s safety.

Your project is a sandbox. Everything inside is accessible. Everything outside is off limits. Simple and safe.