Error Files Editable

When verification finds errors in source files (not test files), those files are automatically added to the edit allowlist so the agent can fix them in subsequent iterations. This bridges the gap between strict file edit restrictions and the need to fix source code issues caused by new tests.

Why This Exists

File edit restrictions block source file edits by default to prevent the model from modifying production code. But sometimes a new test file reveals a real issue in the source: a missing export, an incorrect type signature, or an unhandled edge case. If the type checker or linter reports errors in a source file caused by the new test, the agent needs permission to fix it. Without this feature, the agent would be stuck in a loop - it knows the fix but cannot apply it.

Why Models Need Dynamic Permissions

When a model generates a test that causes type errors in a source file, it knows exactly how to fix the source file but can't because of file edit restrictions. The model can see the fix but can't apply it, leading to frustration loops where it tries increasingly convoluted workarounds in the test file instead of making the simple fix in the source file.

How It Works

After each verification step (e.g., type checking, linting, test execution), GitAuto parses the error output to extract file paths. If any error file is a source file (not a test file) and is not already in the allowlist, GitAuto adds it. The agent is then informed that these files are now editable and can fix the errors in the next iteration. Only files explicitly mentioned in error output are unlocked - this prevents the agent from using verification errors as a pretext to edit unrelated source files.

Related Features

• File Edit Restrictions - the default restriction that this feature selectively overrides
• Type Checking - one of the verification steps that can trigger file unlocking