What the vault is
Your vault is the folder where Shadow keeps user-visible meeting data. It contains Markdown plus available media, so you can inspect it in Finder, use it with a notes app such as Obsidian, or give another local AI agent access on your terms.
Shadow manages only these entries at the vault root:
Meetings/People/Unsynced Files/SHADOW.md.shadow/
Other root entries stay outside Shadow's managed area. A folder used only by Shadow is still the simplest setup.
Folder structure
Meeting bundles normally follow this pattern:
Meetings/
A bundle contains a title-named meeting anchor plus files such as Transcript.md, Notes.md, Outline.md, Skill-result Markdown, screenshots, and saved audio when available. People/ contains persistent Person pages linked to meetings.
Open SHADOW.md in the vault for the current schema guide.
Upgrading the vault format
The portable-format upgrade keeps your existing vault in the same folder. Shadow stores each account's search index and recovery records locally, outside that folder. Restarting with the current vault reads its files without creating an archive or recreating missing content.
In Settings → Meeting → Vault location, choose an existing Shadow vault to transfer your current managed files into it. A populated destination offers Import or Skip. Import reads the destination's content where it is and never changes its files, so it needs no archive. Skip moves its originals into Archived Vaults and does not import them. Your current meetings and app-only retained records stay in the active collection. The source folder stays unchanged. An empty destination needs no Import/Skip decision and receives the current managed files. The progress dialog counts the files and folders copied or archived, then the meetings and People imported and saved. Older compatible vaults upgrade in the selected folder first. Initial setup uses the same Import/Skip decision: Import leaves the selected folder's files as they are, and Skip archives them before starting fresh. There is no owner or Me reinterpretation question for these compatible vaults.
You can use one vault from several Macs, signed in to the same account or different ones. In initial setup and in Settings → Meeting → Vault location, Import reads the selected vault where it is and never changes, moves or deletes its files, so it makes no Archived Vaults copy. Every meeting and Person keeps its Shadow Reference ID, so the other Macs see no deletions or edits. Shadow only adds new files: in initial setup, the meetings and People that were only on this Mac (including the demo meetings); in Settings, your current vault's files, added beside the selected vault's. A meeting or Person the selected vault already has keeps the selected vault's page, and a different meeting with the same folder name gets the next numbered folder. Because Import doesn't copy the vault first, a vault in iCloud Drive or Google Drive no longer has every file downloaded, copied and uploaded again. Skip copies the originals and then clears them from the folder, which clears them for every Mac using it. A meeting with no transcript lines still has a Transcript page, so it syncs to your other Macs like any other meeting.
Shadow works from the files in the vault the same way, whichever Mac or account wrote them. When a file another Mac wrote is valid, Shadow applies it as it is and does not write its own version back, so the Macs don't keep sending the same file to each other. The Materials list in a meeting page and the Meetings list in a Person page are generated; a list that differs from what this Mac has is kept as written and is not saved in Unsynced Files. Shadow never changes a file's Shadow Reference ID. If the page at a meeting's location now carries another meeting's Shadow Reference ID, Shadow first looks for the meeting's own page in the same month (a cloud drive may have renamed its folder). If it isn't there, Shadow leaves that folder as it is and tells you it couldn't match the file. Deleting a meeting or Person on one Mac still asks for review on the other Macs before anything is removed there.
The same Import runs when Shadow finds a different vault at your saved vault location and you choose Import. If an Import can't finish, Shadow undoes it: the selected vault's files stay exactly as they were, the files it had started adding are removed, and nothing is imported, so you can try again.
If the selected folder changes before opening finishes, choose it again. If opening saved successfully but its final local step failed, Try again finishes that saved operation. It does not repeat the import or discard the saved review. Later keeps recovery pending; use Finish recovery in Vault settings to return to it.
If an older vault finishes its format upgrade but opening is interrupted, it remains in that folder with its original documents. Select it again to finish opening. A failed opening keeps the previous vault's app records and selection.
When upgrading an older vault, a missing or unreadable search index does not require a new folder. Shadow rebuilds the index from readable meeting and Person files. If initial setup fails before saving the new selection, the previous selection and app records are kept.
If a Markdown file was already missing, the upgrade keeps the app's retained record and its deletion review. It does not recreate the file automatically. When upgrading a previously configured vault from 2.3.x, an update screen appears before the old format is converted. The library remains unavailable until that upgrade finishes; ordinary sync afterward runs in the background. Large libraries can take longer. The update runs outside the app's UI process.
If a file in your vault would stop the upgrade, for example a note in People that isn't a Person page, Shadow moves just that file (or that meeting's whole folder) unchanged into Unsynced Files/Rejected Sync and finishes the upgrade. If the app already had that item, it asks whether to restore or delete it; Restore writes it again from what's saved on this Mac.
If an upgrade cannot finish, recovery data is kept and the screen offers Try again and Quit. Fix the reported issue and retry, or quit and reopen the app. A failed upgrade does not become successful just because time has passed. If the app closes during an update, saved recovery state is checked when it reopens.
When upgrading a previously configured vault at startup, an older Mac's device record does not prevent the upgrade. Shadow rebuilds the search index locally from the vault's files and preserves records kept only in the app. An unfinished older operation still needs recovery before the format upgrade can finish.
People and participant identity
In the portable vault format, the person who recorded a meeting is saved as an ordinary Person, with their name and email. Shadow marks someone as Me when their saved email matches the account you are signed in with, ignoring letter case and surrounding spaces. A connected Calendar account does not change that label. A legacy Speaker 0 or a missing email alone does not identify you.
Your own Person also has a page in People in the vault, like everyone else, so your AI agents see you in the same context. The People page in Shadow lists only other people and hides yours. If you used a version of Shadow from before October 6, 2026, which removed your own Person, Shadow restores it from your account name and email the next time you open Shadow and links it back to your meetings. When you rename your own Person page in the vault, Shadow also changes your name in Settings → Account to match.
Opening the vault with another account keeps the saved people and their links. Each account remembers its own vault selection. Choosing another folder for one account does not change the other account's selection. Changing your profile name updates past meeting identities only when you choose to update that history, and only for the matching email.
Edit safely
Edit managed data in Shadow when possible. Supported direct Markdown edits include meeting fields, transcript rows, notes, Skill results, and Person details. Shadow preserves unrelated notes under separate second-level headings where supported.
Large batches of file edits sync in the background so you can keep using Shadow. When Shadow reopens, it checks file contents even if your editor or cloud service kept the original modification date. If a copied meeting folder or Person page has the same saved identity as an existing one, Shadow leaves the copy untouched and does not import or report it. Renaming the original folder is still supported. Sync progress appears in the lower-right status card. It says what Shadow is doing, such as Syncing new files from your vault, Applying your vault edit to a named meeting or Person, or Saving your changes to the vault, and shows how much of the whole job is done, for example 3,200 / 10,000 meetings. After a restart, unfinished work continues as Resuming vault sync from the count it reached. Meetings and People appear in the Library and People, with updated meeting counts, as each batch is saved, without waiting for the whole import. Shadow checks your vault quietly; the card appears only when there is something to update. When that work finishes, even after a moment, the card shows Vault update complete (or Synced and the number of meetings for new files) for three seconds before it closes. When that count is complete, Shadow still finishes the job: it checks the imported files again, saves a restore point, updates each imported meeting file, and saves the vault's file list. The card's title changes to say the import is done, for example Synced 10,000 meetings · finishing up, and names each of these steps with its own count, for example Updating meeting files 4,100 / 10,000 meetings. A step's count starts from zero, but nothing is imported again, and the job's import count never goes backwards. If files are still arriving while Shadow imports, for example during a large copy, they are part of the same import: the count keeps going, such as 5,487 / 8,187 meetings, and between steps the card says 5,487 meetings synced · Looking for more new files. Files that Shadow did not create take longer, because Shadow rewrites each one in its own format. Cloud drives such as Google Drive can deliver a meeting's files one at a time. When a meeting's page arrives before the files it lists under Materials, such as its Transcript.md, Shadow waits for the rest instead of reporting an error. It checks again as each file arrives, and every 10 minutes otherwise, for as long as it takes, then imports the meeting once every listed file is there. Vault tasks run one at a time. If a task has to wait for another one, its status names the task it is waiting for and that task's progress. Deleting a meeting or Person that has to wait for a vault task says the same instead of showing only a spinner. You can start Listening without waiting for a Vault update to finish or pause. Vault work pauses safely in the background, and its status card stays hidden during Listening. While a stopped recording finishes saving, the card shows Finishing a recording before syncing your vault. Queued work and its progress resume after that.
Do not edit .shadow/ metadata or rely on a fixed internal layout. If Shadow cannot safely apply an external change, it preserves the change under Unsynced Files/ for review.
In a portable vault, if the same notes, transcript, Skill result, meeting fields, or Person details change both in Shadow and in the vault before syncing, Shadow keeps a readable copy of the local edit under Unsynced Files/ and applies the vault version. The notice shows where that copy was saved. Identical edits do not create extra copies. Changes to formatting alone keep any pending edits in Shadow.
Person name and email updates run in the background, whether you edit in Shadow or in your Vault. You can keep using the app and save another change to the same Person while related files are updating. The latest valid details take over the remaining update; an invalid later change does not undo an earlier valid one. Listening takes priority and pauses Vault work. Updates resume afterward, and accepted queued Person updates resume when Shadow reopens. Failed updates keep their recovery state and provide a retry action. Existing meeting references can still identify the same Person while older names and emails are being updated, including after restarting Shadow. This temporary lookup does not reserve an old email address. A large Person update takes longer because Shadow rewrites every meeting that Person attended. The status card shows Updating the meetings Alex attended with a count, for example 2,500 / 10,000 meetings.
Deleting a Person works the same way. Shadow removes that Person from the attendees of every meeting they attended, and each speaker assigned to them goes back to an unassigned Speaker N (the lowest number free in that meeting). The transcript lines stay. The status card shows Deleting Alex and Removing links from meetings with a count, then each remaining step, such as Updating People files, with its own count. If the update is interrupted, the card shows Waiting to continue until Shadow retries.
A Person page's Meetings list is generated from actual attendance. Editing that list does not add or remove attendance, even if a link points to an existing meeting. Missing meeting links are ignored; valid name and email edits still apply. The next export regenerates the list.
When an edit to an existing managed file cannot be applied, Shadow moves the edited file to Rejected Sync and keeps the previous normal item in the app. Choose Restore to rebuild the normal version, or Delete to remove the item from Shadow as well. Rejected edits are not restored automatically. For a rejected Meeting bundle, available quarantined media is restored alongside the normal meeting text. A newer edit must be reviewed again before either action. New files without a previous normal version remain a separate import rejection.
You can rename Meeting and Person Markdown pages without deleting their records. Keep the Shadow Reference ID and supported document format. Meeting folders can also be renamed within the dated folder layout. Shadow compares the filename, folder name, and document fields with the last accepted version. Changing only a Person filename updates its name; changing only a Meeting filename or folder title updates its title. Editing only the document's name or title uses that field. The optional Person email suffix is not part of its display name. If a Person identity edit needs a filename that is already occupied, Shadow keeps the existing file and adds a number to the managed filename, such as Jay (jay@example.com) (2).md. The number does not change the Person's name. New Person files and Meeting folders use the same numbering when their path is occupied. Existing files and folders stay untouched, and the number does not change the name or title shown in Shadow. Changing the email to one already used by another Person is still rejected.
For a Person page, an edited name or email line is used as written, whatever the file is called, and Shadow doesn't rename the file to match. For a Meeting, when the folder name and the title change together, the new titles must agree. Conflicting titles or unsupported formats move to Rejected Sync for Delete/Restore review. Email edits continue to use the document's email field. Person email addresses must be valid in both the filename suffix and the document. Incomplete email suffixes, unclosed quotes, duplicate name/email fields, and malformed email addresses move to Rejected Sync. The previous Person stays in Shadow until you choose Delete or Restore. An empty email field is still supported. Meeting attendee and speaker tables also require valid email addresses and readable columns. A broken table is rejected; it is never treated as a request to remove every attendee. An intact table with no attendee rows remains a supported way to clear the attendee list. Changing an existing Meeting's start or end time to an unreadable value, an impossible date, or an end before its start also sends the edited page to Rejected Sync. Clearing a previously populated time requires the same review. The app keeps the previous Meeting until you choose Restore or Delete.
Shadow evaluates the filename or field you changed. Valid edits apply. Only the file that can't be read moves under Unsynced Files → Rejected Sync, with its edited bytes: the Person page, or the meeting page while the meeting's other files stay and import. An invalid rename of a meeting folder moves that folder with its media. The item is removed from the active Vault, while its previous normal state stays in Shadow pending Delete/Restore review. Shadow does not restore the old value or recreate the file automatically during later syncs. Fix the saved file and move it back to its Meetings/People path to import it again. Duplicate or conflicting references are not merged. Files that were actually removed still use the existing deletion review.
When Shadow can't import a file, or saves a copy of a vault file, you get the same notification either way, naming the file and where it went. Click Review to open the notice inside the app. It lists each file and says what happened, for example that a person was added and their file renamed, and that your original is in Unsynced Files. Rejected files move to Rejected Sync; fix them and move them back to try again. Expanding Review shows full source and saved locations. Dismiss closes the notice without removing the saved files.
If content was removed in Shadow while its vault file received a new edit, Shadow keeps both states unchanged and reports the conflict. For notes, transcripts and Skill result text, expand Review or open Settings → Meeting → Vault content conflicts. Use Vault version restores the newer text immediately. Delete newer content… shows the original folder, file and newer text before confirmation; it clears the contents while keeping the file. Cloud sync can carry that deletion to other devices. Changed content requires a fresh review. Dismissing the notice does not remove the conflict from Settings. Whole-meeting and media conflicts remain separate.
If changes have not reached the vault, Shadow keeps them with the account and vault where they started, including after a restart. Changes for another vault wait until you open that vault. An unverified original folder remains local and is not sent to the folder you happen to select next. Settings doesn't list these pending changes.
Changes to a meeting still being recorded remain pending until it finishes, even when other meetings in the same batch have saved. If Shadow cannot match saved changes to their original records, it keeps them for recovery instead of repeatedly retrying them in the background. If app data changes while files are saving, Shadow makes up to three fresh attempts. If the changes continue, Shadow keeps them pending instead of retrying in a loop.
A recording's pending save stays with the account and vault where it started, including after an app restart. Opening another vault does not send that save there. If finalizing its pending save fails repeatedly, Shadow stops retrying in the background and keeps it for the original vault. A recording awaiting recovery in another vault becomes available when you select that vault.
If you change accounts or vaults before a recording finishes, its later transcript, speaker and title updates cannot be saved into the newly selected vault. Recovery, audio checks and completion confirmation stay with that original recording too. Google Meet captions and their participant updates follow the same original recording, including captions delivered after a switch. Reopen the original vault and retry recovery. A failed save keeps the recording's recovery data; it is not treated as a completed recording.
Screenshots keep the account, vault and meeting where capture started, even if capture or image analysis finishes after you switch. If an image cannot be saved to that meeting, Shadow keeps the image locally. Returning to the original vault can resume eligible saved captures. A missing or replaced meeting is not recreated.
If a Skill finishes after you switch accounts or vaults, its result stays with its original account and vault, and Shadow keeps it locally. When you return to the original vault, eligible results can resume automatically. A deleted meeting or a result you already changed is not overwritten.
Edits in a Skill result follow the same rule. Closing its preview still saves the last captured edit to the original meeting. If the saved result changed elsewhere, Shadow keeps your edited version locally instead of overwriting the newer one. Switching accounts closes the old preview.
Running a Skill again keeps its saved result until the new result is ready. If the run fails, use View saved result or Copy from the result card.
Deleting a Skill result asks you to confirm the meeting, Skill and folder. This also removes its locally kept versions and cancels unfinished runs and edits. If the result changes while the confirmation is open, open Delete again to review it. A cancelled or failed deletion keeps the saved result. Starting a new run after a confirmed deletion can create a new result.
Retrying a whole meeting asks before removing its previous Skill results, locally kept versions and chat history. The confirmation shows the meeting and vault folder. Cancel keeps them. If a result or message changes while the confirmation is open, review the new contents before retrying. A first run with nothing to remove proceeds without asking. Recordings, transcripts and notes stay in place.
Automatic Skills and meeting retries keep the account and vault where they started. Switching either does not send an old task to the new vault. Reopen the original meeting to retry interrupted processing.
Changing a speaker saves the assignment and its related text together. If saving fails, the previous content stays intact and your draft remains in the picker for another try. If you switch accounts or vaults, reopen the original meeting before retrying. A change that was saved before you switched stays with that original meeting.
If Shadow says a result has not been saved to disk, keep Shadow open and copy the text or retry saving before closing the app.
Deleting a managed meeting, Person page or meeting child file outside Shadow triggers a review. Delete opens the existing confirmation overlay before removing retained content from the app. Sync Deletion for a missing vault also asks for confirmation. Cancel, Escape or switching accounts or vaults keeps the retained data and review. Restore retains its existing behavior. While Shadow restores or deletes the reviewed items, the progress dialog counts the items finished so far, for example 4,000 / 10,002 items. Steps that follow the count, such as updating People files or saving the vault's file list, show their own name and count. Restore also brings back your own Person page if it was among the deleted files.
If the whole vault folder is deleted, or Shadow loses permission to open it, the review offers the same two choices: Restore rebuilds the vault from Shadow's recoverable copy, and Sync Deletion starts again with an empty vault. A deleted folder is recreated at its saved location. When Shadow can't create or open that location, either choice sets up a new vault in Shadow's Application Support folder (~/Library/Application Support/Shadow/User Data/Vault) and leaves the original folder untouched. Restore can't bring back audio or screenshots that were only in the original folder.
When automatic file watching sees 50 or more managed files disappear together, Shadow waits 30 seconds and checks the current folder again before continuing that change batch. This gives a cloud folder time to settle. Files that return are read from disk; the waiting period does not restore files or delete app data. The same check applies when reopening an already configured vault: a large missing group is handed to file watching for confirmation before syncing it. Direct import requests also wait before processing a large missing group and read the current files afterward. Changing the active vault or account during that wait cancels the request; retry it in the intended vault.
New recognized meeting bundles and Person files are imported automatically. Completed imports and accepted file edits are kept if automatic sync is interrupted. When Shadow reopens, it resumes unfinished work using the latest files; each meeting bundle stays together. If an item fails, other valid items can still finish. Try again retries unfinished items without importing completed ones twice. If a waiting file changes before it is imported, Shadow checks its latest contents again. An invalid edit is handled using those latest contents. If a cloud service has delivered only part of a new meeting or Person file, Shadow leaves the files where they are and waits, however long it takes. A new meeting whose page, transcript or listed files are missing, empty, cut off or unreadable may still be arriving, so Shadow doesn't move it, doesn't import it and doesn't tell you about it. It checks again whenever the files change and every 10 minutes, and imports the meeting once it is whole. A new Person page whose Properties are complete but invalid, such as one with no name, still goes to Rejected Sync. If two Macs create the same Person before seeing each other's page, each Mac takes the Shadow Reference ID written in that Person's page, without rewriting the page or keeping a copy in Unsynced Files. Other valid additions can continue syncing. An import failure shows the vault location and Try again; repeated scans do not keep retrying the same failed batch. Files that can't be imported for another reason appear in an informational notice with their paths and reasons. Dismissing it does not move or delete the files, and corrected contents are checked automatically.
When two Macs set up the same cloud folder
Set up the vault on one Mac first. Wait until its files appear on the other Mac, and only then choose the same folder there. If both Macs set up the folder before either Mac's files have arrived, Google Drive keeps both copies and renames one, for example Meetings (1), People (1), .shadow (1), SHADOW (1).md, a month folder such as Meetings/2026/10 (1), or a meeting folder such as 2026-10-14 Weekly (1) that repeats a meeting Shadow already has. Shadow uses only the exact folder and file names it creates, so it ignores every renamed copy: it doesn't read, import, change, move or delete anything in it. To keep meetings that are only in such a copy, move their folders into the right Meetings/ folder by hand, then delete the copy. If your own month folder was the one renamed, Shadow asks whether to restore or delete its meetings; Restore writes them back into the right month folder.
Shadow on one Mac never rewrites what another Mac wrote; it takes each file as it is. If the same meeting or person was changed on both Macs before their files arrived, the change made last is kept, and the other version is saved in Unsynced Files only when this Mac still had a change of its own that hadn't reached the vault yet.
If both Macs added the same person (the same email) before their files arrived, Shadow shows one person on both Macs: the page edited last, with its name. The other page stays where it is and is ignored; you can delete it. The same rule covers every record that ends up in two places: a meeting folder that exists twice, or a copy of a meeting's Transcript.md, Notes.md or Screenshots.md that a provider adds next to it, such as Transcript (1).md or Transcript 2.md. The version edited last is used, an identical copy is ignored, and copies never appear as Skill results. Nothing is moved or rewritten, so a small edit on the other version can be lost.
An edit in Shadow writes only the file it changes: saving a note writes Notes.md and leaves the meeting page alone. If you write a note while another Mac renames the same meeting, the Mac where you wrote the note moves it into the renamed folder once the rename arrives. A meeting folder you make by hand without a Shadow Reference ID is imported as it is; Shadow doesn't add an ID to it.
Change the vault location
Vault changes are unavailable while Listening starts, records, or finishes saving the recording after Stop. Once essential recording data is saved, the folder can be changed without waiting for analysis or Skills. Late results remain associated with the meeting and vault where they started. A blocked change is not queued; select the folder again after saving finishes.
Open Settings → Meeting → Vault location, choose a new folder, and review Import or Skip when the destination contains managed data. Keep Shadow open while it checks, copies, imports, and reconciles files.
Choose the vault folder itself, the one that holds SHADOW.md. Folders inside a vault, such as Meetings or People, can't be chosen; Shadow warns you and asks you to pick again.
Import keeps the destination's files exactly as they are, with no archive copy, and combines recognized destination data with the current collection. Skip copies and verifies the destination's originals into Archived Vaults before clearing them, then copies the current managed files without importing destination data. The source folder remains unchanged.
Back up your data
Shadow can rebuild managed text from its local records, but it cannot rebuild missing audio or screenshots. Back up the entire vault with a trusted local or cloud-sync system. Pause conflicting edits while changing the vault location.
When an older vault's device claim cannot be verified
Vaults upgraded to the portable format have no device owner. A preserved device claim from an older version does not block a portable vault on another Mac.
For older vault formats, use a separate vault folder on each Mac until the upgrade completes. Shadow pauses changes when an older folder's device claim does not match this Mac. The setup screen shows the full folder path so you can identify it before choosing another location.
Shadow keeps its device identity separately from resettable app data. If you already deleted an older installation's identity on the same Mac, the original local identity can be recovered after confirming the Mac and vault, preserving the vault's contents. You do not need to abandon your vault or create a new one. Do not delete its .shadow metadata to bypass the check.
The other-device check applies to a vault owned by your signed-in account on a different Mac. A matching Mac identity remains valid after an app-data reset; a changed installation ID alone does not make it another Mac.
When you confirm quitting during a vault update, Shadow interrupts the background update and keeps its recovery information. It checks the interrupted work when you reopen the app; quitting does not wait for the whole update or file rollback.
If Shadow closes just after saving an edit locally, it recovers unfinished saving work when you reopen the original vault. An edit is marked saved to the vault only after its content has been checked. If another version has replaced that content, the original edit stays available in saved local data for copying or exporting. Reading a meeting or continuing a chat does not create a file conflict.
A screenshot that has not arrived from your cloud folder is omitted from the gallery until its file becomes available. Opening the meeting does not delete its saved screenshot record.
Deleting a screenshot asks for confirmation and shows the file path. Cancel or Escape keeps it. If you switch accounts or vaults, the confirmation closes. If the screenshot changes while you are reviewing it, review the new version before deleting. A failed deletion stops and lets you try again; it does not repeat on a timer. Confirmed deletion may also remove the file from your other devices through your cloud service.
A confirmed screenshot deletion is saved before its file is removed. If Shadow closes midway, it checks the original account and vault before finishing. Failed work stays recorded with that account and vault. A replacement image or changed record stops the old deletion and needs a new review. Shadow does not keep retrying the same failure in the background.
Deleting a meeting from the Library or its meeting page shows the existing concise deletion warning. Cancel, Escape or switching accounts or vaults closes the confirmation without deleting it. If the meeting changes while you review it, reopen the meeting and review deletion again. A delayed response from the original deletion cannot remove a meeting from a newly opened vault.
Shared meeting images and recordings follow the same pending-sync handling as the meeting documents. If file removal fails, Shadow keeps the request. Media changed outside Shadow, or newly arrived files that Shadow has not tracked, are kept for review instead of being removed by an old cleanup request. Files kept for review remain in their vault folder.
If an image or recording cannot finish copying into the vault, Shadow keeps the original source and leaves sync pending. Make sure the vault folder is available.
If a deleted meeting's local files cannot be removed, Shadow keeps an unfinished cleanup request with the original account and vault. The request survives restarting Shadow. New or changed local files stay in place. Restoring the meeting cancels its old local cleanup request.
Shared folder cleanup removes only the files already checked. A new file arriving from another device keeps the folder from being removed.