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.

Before you begin

  • Undra installed on Windows. Folder portals live in the desktop app, not the web demo, so do this one on your own machine.
  • An AI provider connected. Mira runs on the AI subscription you already have, or a local model. See Setting up AI.
  • A real folder you care about. Not an empty test folder; the next section explains why.

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: connecting is also a boundary decision. Undra limits AI file access to folders you have brought in - your workspace, your connected portals, and folders you explicitly approve when the AI asks - so pointing it at this folder does not open up the rest of your machine. Two things sit outside that file boundary, and it is worth knowing them now: terminal commands the AI runs are not confined the way file edits are, and external tool servers you connect follow their own rules. The fence is real; it fences file access, not everything.

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 is grounded in that folder: it reads there, and it directs its changes there.

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, with its attention anchored to 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 run’s file changes. One scope note: a terminal command the AI runs is not a file edit, so its effects are not part of undo. 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 file boundary that kept the AI inside folders you chose 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.