Last updated

Work safely on a real folder with a portal and AI edits

By the end of this walkthrough you will have pointed Undra at a real folder on your computer, asked an AI chat to make a change that spans several files, watched every edit land as it worked, undone the whole batch in one click, and pulled a deleted file back out of Undra’s backups. The point is not the steps. The point is the feeling you walk away with: letting AI touch your real files is safe because anything it does, you can see and reverse.

That confidence is the whole reason portals exist. Most people keep AI at arm’s length from their actual work because a bad edit feels permanent. Here it is not. Once you have undone a run and recovered a file by hand, the fear drops away and you start handing the AI bigger jobs.

Desktop only

Folder portals live in the Undra desktop app. They are not part of the web demo, so do this one on your own machine.

Pick a folder you would be nervous about

Use a real folder, not an empty test one. A project directory, a pile of loose notes, a messy downloads folder: something where a wrong edit would actually annoy you. That nervousness is the thing this walkthrough is meant to dissolve, and it only dissolves if the stakes are real.

If you want a copy you can throw away first, duplicate the folder in your file manager and aim the portal at the copy. There is no shame in training wheels for the first run.

Connect it as a portal

Bring the folder into Undra as a portal. Nothing is copied and nothing moves. The portal is a live link to the folder where it already sits on disk, so editing through Undra edits the real file, and changing the file outside Undra shows up inside. The exact ways to connect it, and the permission prompt that confirms the path first, are in Folder portals.

Why this matters before you go further: the portal is also a fence. Once the folder is connected, the AI you talk to inside it can reach those files and nothing else. Not the rest of your computer, not the rest of your workspace. That boundary is automatic, so you are never trusting a prompt to stay in its lane.

Scope an AI chat to the portal

Attach the portal to your chat with a Scope pill in the composer (pick the portal folder from the scope menu), or open an AI chat from inside the portal folder and Undra scopes it automatically. Either way, the AI reads from and proposes changes to that folder, and only that folder.

You do not have to browse into the portal first. Scope pills let you point any workspace chat at a code project or asset folder when you need it. See Folder Portals for the full picture.

This is the part that makes a portal different from pasting code into a generic chatbot: the AI is grounded in your real files, and it is boxed into the one place you pointed it.

If you have not connected an AI provider yet, do that first in Setting up AI. The write, see, undo model you are about to lean on is the same one Mira uses, explained in Mira.

Nothing here waits for approval

Every file change the AI makes applies as it works, deletions included. There is no approval queue to sit in front of. What keeps that safe is the backup taken before anything is overwritten or deleted, plus one-click undo for the whole run. Folder portals has the exact mechanics.

Ask for a change that touches several files

Give it a job big enough to be interesting. Some honest examples:

  • “Rename every config.old in here to config.bak and update any file that mentions the old name.”
  • “Sort these loose files into folders by year and delete the empty temp folder when you are done.”
  • “Add a one-line header comment to each script and remove the dead scratch.txt.”

Notice that each one mixes edits (create, edit, rename, move) with at least one deletion. That mix is deliberate: it lets you watch the destructive case get protected the same way the safe ones do.

You get a change card in chat that lists every file touch. It is a record of what happened, not a waiting room. The whole set lands as the AI works.

Watch what actually protects you

Nothing in that run paused for you, and that is the point. Two things happened quietly instead:

  1. Every change applied as it was made. Creating, editing, renaming, moving, and deleting all went straight to disk, so you read results rather than approving steps.
  2. Anything destructive was copied first. Before a file was overwritten or deleted, Undra put a copy in its own backup storage, outside your folder. That copy is what makes the next two sections possible.

That is the design in one sentence: move at full speed, but never lose the previous state. The exact backup behavior is documented in Folder portals.

Undo the entire run

Now do the thing that makes all of this real. Undo the run, the whole batch of changes, in one click. The renames, the edits, the move, all of it rolls back together. You do not unpick changes one at a time, and you do not have to remember what touched what.

This is the experience worth internalizing. You did not just read that edits are reversible. You reversed a multi-file change a machine made to your real folder, and your folder is fine. That is the trust layer working as intended.

Recover a deleted file by hand

Undo already brought the deleted file back, so now do it the other way, without undo. Run the request again, then open the run’s restore bar in chat and click Open backups. The copy Undra took before deleting is sitting right there, and you can drag it back into place yourself.

These backups live in Undra’s own app data, deliberately not inside your project folder, so they never show up in git status or sync with your files. Do this once by hand. Seeing your “deleted” file sitting safely on disk is what turns the promise into something you actually believe.

Backups expire after 7 days

A deleted or overwritten file is copied before the change, not destroyed, so it is recoverable. Undra clears those backups after 7 days. If you want something kept longer, move it somewhere safe yourself.

Why this feels safe instead of risky

Step back and notice what just protected you, because none of it was you being careful. The boundary that kept the AI inside one folder was automatic. The change card listed every file touch. The backups happened before any overwrite or delete. The undo was one click. The recovery was a real file you could pick up by hand.

That is reversibility used as trust. You do not stay safe by reviewing every keystroke and hoping. You stay safe because mistakes are cheap to take back, so you can let AI move quickly without betting your work on it. The principle underneath all of it is in Local-first trust: if something changes your files, you can always tell what it changed and undo it.

Where to go next

  • Folder portals: every mechanic touched here, including how to connect, the backup window, and undo.
  • Mira: the assistant, and the write, see, undo model Mira uses inside a portal.
  • Local-first trust: the reversibility principle that makes leaning on AI here safe by design.