The code editor

Vaulter apps are real code, not a locked black box. The Code tab in the build workspace shows every file behind your app in a full editor, the same one that powers VS Code, with a file tree to move around. Most people never need it, and there is one important caveat.

When editing code helps

Direct editing is useful if you are comfortable with code and want to:

• Make a precise change faster than describing it.
• Adjust something specific that is easier to express in code than in words.
• Read how a part of your app actually works. The Code tab is worth opening even if you never type in it; watching what the agent wrote is the fastest way to learn your own app.

The one big caveat

Editing code by hand can break your app in ways the agent did not intend. When the agent works, it keeps the whole app consistent: data, pages, and logic move together. A hand edit can quietly conflict with that. If you are not sure what a change will do, it is safer to describe what you want in chat and let the agent make the change.

A good default: use chat and Edit Mode for almost everything. Reach into the code only when you specifically want to, and know that you are taking the wheel when you do.

After editing

Vaulter still rebuilds and checks your app after manual changes, and the self-repair layers catch runtime errors and blank screens the same as always. But auto-fix repairs what is broken, not what is misunderstood; it cannot know your intent. Test your change in the preview before publishing.

A note on database changes

Schema changes are special: they run as migrations with their own guardrails. If you write one by hand, destructive operations like dropping a table require explicit confirmation, and a failed migration shows up in the Database panel with its error rather than silently breaking your app.

Where things live in the code is covered in Project structure.