aiedit hides individual lines of code from an AI agent: 5 levels and 857 tests

The aiedit editor locks specific lines, not files, away from an AI agent, and it does so at the code level rather than by asking in a prompt. The project was written by a beginner developer who has been learning Python since late September 2026; Claude wrote the code under his direction. The result is about 11 thousand lines of code, about 10 thousand lines of tests, and 857 tests that pass on both PySide6 and PyQt6. The license is MIT. Models are called through plain HTTPS requests without an SDK, so Anthropic, OpenAI and any OpenAI-compatible server will work.

Why ignore files don't protect you

The idea grew out of weaknesses in existing tools. Cursor's documentation states outright that terminal commands and MCP tools "may read" files listed in .cursorignore. Cline removed .clineignore altogether: according to the project, the file "was never designed as an access ban," and the authors do not want to give users a false sense of security. On top of that, such files work only on whole files. If you split a project into "AI can touch this" and "AI can't," the agent works blind. aiedit keeps the project intact and locks down only specific spots, such as a price calculation formula or payment handling. The model sees and edits everything else.

Five levels and a chain of five protections

You lock lines directly in the editor's line-number gutter. The access levels are:

• hidden: the model receives only a marker such as <<ai-hidden:0:5 lines>>, so it knows something is there and how many lines it spans;
• interface: names and signatures without function bodies (for Python);
• readonly: all the code is visible, but any edit is rejected;
• confirm: all the code is visible, and edits go through only with the author's approval;
• explain: the model explains this code.

A chain of checks runs on top of the levels:

• the model has no terminal, only the editor's tools (read, search, edit), and locked folders do not exist for it;
• every edit is checked with a diff, and if it touches a locked line it is rejected; nothing is written to disk without approval;
• tests and the program run under bubblewrap on a copy of the project that physically contains no locked code, with no network, home directory or keys. Even dumping every file as base64 would reveal nothing;
• an outbound filter looks for keys, words from a list, and locked lines pasted into the chat, and offers to mask, send or cancel;
• a local log records which files were sent, how many lines were hidden and how many characters were transmitted, and any applied AI change can be rolled back.

There is also a separate multi-model pipeline: one model writes the code, the editor itself runs the tests in the sandbox, and a model from another vendor looks for bugs and holes. Only after that does the author see the changes, together with the real test results rather than a claim that "everything works."

How the protection broke the code the model wrote

The author's comparison with Claude Code is unvarnished. On a "simple Flask app" task, Claude Opus 5.5 wrote the code both in aiedit and in Claude Code, but in aiedit GLM 5.3 additionally reviewed the edits, and the result was worse. The log revealed the cause. The model wrote "password": "secret123" in the tests, the secrets filter took it for a real password, and in the sandbox the line turned into raise NotImplementedError right inside a dictionary. The file was no longer valid Python. Of 22 sandbox runs, 13 failed, and pytest never got as far as the tests themselves. The model did not understand the cause and wrote six more test files to get around it.

The fix: now only the value is replaced, "password": "<hidden>", and the syntax is preserved. The author did not rerun the test on live models; the fix is confirmed by a test that reproduces the case. Results with local models are also uneven: qwen2.5-coder 7B could not hold the tool-call format, while the 32B version handled simple tasks but did not finish a multi-file one within 14 steps.

Reading through the code also turned up two holes, both now closed. If a file was renamed or copied outside the editor, its zones were lost; locked code is now recognized by line hashes. And a project installed into its own .venv via pip install . sat there in full, so a command in the sandbox could read it; such copies are now hidden.

Where the protection ends and what to take from it

The author lists the limitations candidly. The filter catches only what it can compare against: key patterns, words from a list, and locked lines pasted verbatim. A paraphrased secret will get through.

A signature like calc_discount_for_client_x() in the interface zone already gives away the meaning. Everything not locked goes to the model provider. The editor will not recognize a modified copy of locked code.

The hashes in *.aimarks.json are unsalted, so a short line like rate = 0.

15 can be brute-forced, and these files must not be published in a public repository. The sandbox works fully on Linux; on macOS it is experimental and has not been tested on a real Mac, and on Windows it works only through WSL.

The practical takeaway for teams that let agents into commercial code: protection should live in the tool layer, not in the prompt text. Taking away the agent's terminal, a sandbox with a copy that has no secrets, diff checks on edits and an outbound filter give verifiable guarantees. There is a visible side effect too: the more aggressive the masking, the higher the chance of breaking code validity, and request logs become the main debugging tool. The code is available on GitHub and GitFlic, and the author asks people to send in ways to bypass the protection.