Edit an App
Edit an App's files by typing, or change its design by describing it: nothing applies until you accept.
An App keeps its files in Kortecx, not on your disk. Its saved set of files is called its branch. There are two ways to change it, and both end at the same place.
- You type. Open a file, change it, save.
- You describe. Write one sentence about what you want changed, and the agent proposes a new design for the App: its steps and the tools they use.
The second way is the one that needs a safety net, so that is where this page starts.
Nothing applies until you accept
When you describe a change, Kortecx does not write it. It designs the change against the App as it is saved and returns a proposal for you to read.
Describe the change. In the console, open the App and use the Modify
action in the App header. Type the instruction in plain language — for example,
add a step that checks the summary before it is posted.
Read the proposal. The runtime designs the change against the App as it is saved, so the proposal is the whole App with your change in it, not a patch.
Read its notices. The proposal lists any limits it had to note, such as a tool it named that you cannot use.
Approve, or reject. Reject discards the whole proposal and returns you to the instruction box; the proposal was only ever held aside for you to read, so nothing in the App moved. Approve saves it over the same App, in one save.
Undo by changing it back. There is no roll-back button and no saved history: describe the change back. A copy you downloaded before you approved shows what the App was.
Keep a copy first
A saved App keeps no history of earlier versions. Before you approve a large change, download the App so you hold a copy of what it was.
What a described change touches
A described change reshapes the App's design, not one file's text: it does not change a file's contents. And a locked App cannot be changed this way until you unlock it.
Describing a change needs a model available, because a model is what writes the proposal. Reading files, typing edits yourself, locking, and unlocking all work with no model at all.
Typing an edit yourself
In the console's Files tab, select a file to view it. The console shows files read-only.
Reading the App's shape
Files are one half of an App. The other half is its structure — the steps the App runs and the edges between them.
The console shows the same thing as a diagram in the Lineage tab. Both are read-only views — they tell you what the App is, they do not change it. Structure is authored where the App is built; see Apps.
Lock it when you are done
An App that works is worth freezing. A lock is a switch on the App's project branch, set by you, that refuses writes.
While the lock is on, the runtime refuses:
- file edits — any change to a file in the App's branch, whether it came from the console, the CLI, an SDK, or the agent;
- structure edits — re-saving the App's shape, so what it runs cannot be changed either;
- scaffolding — the agent cannot write a fresh project tree over it.
Refusals come back carrying the code app_locked, so a tool can act on the code rather than
on the wording. The console checks the lock first and shows a notice in place of the editing
controls, rather than offering you a control that will fail.
Running the App is unaffected. A lock stops the App from being changed, not from being used.
What a lock is not
A lock is yours alone: it is held against your identity and the App's handle, so you can only lock, unlock, and see your own Apps. It is an availability switch, not a security control or an integrity guarantee — the switch is kept beside the App rather than inside it, and if it is lost or rebuilt, branches read as unlocked and editing is restored. That is the deliberate direction: losing it can never leave you unable to edit your own App. Do not treat a lock as tamper-proofing.
Review a change before it applies
Open the App, choose Modify in its header, and describe the change in a sentence. The console shows the proposed design, then waits: nothing is written until you approve, and approving saves it over the same App.
When a model authoring an App's files answers a file empty, that file is left as it was, so a model that answers with nothing cannot blank a file.