Overview of GameCatalyst’s Safety Features

GameCatalyst layers multiple safety features on top of each other so that no single point of failure can cause damage to your project. Even if one safety check is misconfigured, other layers catch the problem before it reaches your files. Here is how all the safety layers work together.

Permission layers (4 deep):

1. Command Definitions — A command must be defined in a CommandDefinition ScriptableObject asset to exist at all. If the asset does not exist, the command is invisible to AI clients.
2. Project Permissions — The command must be enabled for the specific Unity project in the database.
3. Engine Session — The command must be allowed in the active engine session between Unity and GameCatalyst.
4. Client Session — The command must be allowed for the specific AI client that is connected.

A command must pass all four layers to execute. Fail any single one, and the command is rejected immediately with a clear error message.

Filesystem safety:

• Dry-run default — All file write operations simulate changes unless you explicitly set dry_run: false. You see what would happen before it actually happens.
• Protected paths — The directories .git, Library, Temp, and Logs are permanently shielded from all AI access.
• Project containment — AI cannot touch files outside your Unity project root directory.
• Whitelist mode — File paths must be in allowed directories to be accessed.
• Max depth limit — Directory traversal is limited to 10 levels by default to prevent runaway scanning.
• Max file size — Read and write operations are capped at 1 MB by default to prevent accidents with large binary files.

Behavioral safety:

• DAP enforcement — Vex must discover paths before acting on them. No guessing allowed.
• Verification gates — Vex verifies each step in a workspace plan before moving to the next one.
• No placeholders — Vex never uses temporary names, stub values, or “coming soon” markers in your code.
• No assumptions — Vex verifies facts using discovery commands instead of guessing.

Architectural safety:

• Thread-safe execution — Commands run on Unity’s main thread via MainThreadDispatcher, preventing race conditions and crashes.
• Recompile resistance — Sessions survive Unity recompilation without any data loss.
• PID singletons — Prevent duplicate server instances from accidentally launching.
• Port guards — Verify port availability before binding to prevent address conflicts.

Every layer works together to form a complete safety system. Permissions control what Vex can do. Filesystem safety controls where Vex can operate. Behavioral safety controls how Vex approaches work. Architectural safety ensures the system itself stays stable. The result is an AI assistant you can trust with your project.