An AI Workspace Migration: Broken Links and the Limits of Hash Checks

The sessions and automation attached to a folder

I originally kept documents apart from code so I could read them on mobile devices. In practice, much of the work involved reading documents and editing code with AI on a computer. I decided to bring both locations under each project.

project/
├── docs/    Articles, plans, research, and verification records
└── code/    Source code and runtime environment

AI sessions would start in the parent project folder. I set the storage and preservation requirements and delegated inspection and migration to AI. When a path problem appeared during use, I asked it to check other places using the same rule as well.

Moving the files also affected saved session locations, virtual environments, scheduled tasks, and document links. A link from an old path to a new one could let a file open without making its actual storage location obvious. I asked AI to check both the path and its target.

A folder name changed the automation’s target

The automation connecting a kanban board to reminders treated the first path component as the project name. In the new structure, that component was a broader category.

Before: project-a/tasks/item
After:  work/project-a/docs/tasks/item

The old rule would read work as the project instead of project-a. The session records the resulting category-named lists and duplicate items, followed by corrections.

AI reported changing the project-name parser and synchronization while preserving existing item IDs and links. Where completion was unclear, I asked it to compare the verification record with the current state again. The check needed to include a completed synchronization cycle after restart, beyond whether the configuration had been edited.

The relevant measure was whether the automation still referred to the same tasks, rather than how many files had moved.

A OneDrive link mistaken for an obsolete path

The investigation into files that would not open exposed another error. AI acknowledged that a link it had removed as obsolete was still being used by the running OneDrive app. It also corrected its earlier statement that the active OneDrive setup had been untouched.

According to its follow-up report, the data and staging directories remained at the new location. AI restored the link, downloaded files through both personal and work accounts, and checked the ZIP structure and workbooks of sample Excel files. That report supports those downloads and sample checks passing. It does not establish that every archived file was healthy.

The mistaken inference was that an old-looking path had stopped being used. Without comparing app settings and actual use, removing a link can cut off access even when the data remains intact elsewhere.

Matching hashes and healthy files

Separately from the download connection problem, some older SSD archives were reported to have file sizes but no usable content. AI acknowledged that proposing deletion on the basis of matching hashes had been insufficient. Two copies with the same empty contents or damage can compare as identical.

Check	What it can establish	What it cannot establish on its own
Path and file existence	An item exists at the specified location	The app actually uses that location
File size and hash	Bytes match across copies	The contents are healthy and represent the needed original
File-format validation	The inspected file has a valid internal structure	Every file and business workflow works
Downloading and opening through the app	The tested file is usable through that path	Untested archived files are also healthy

AI reported restoring archives from healthy originals. It left files unresolved where, for example, the original could not be found or its size differed. Its final report also said the file I had originally been unable to open still needed a direct check. I did not find follow-up evidence establishing that this final check was completed. This account therefore does not conclude that the entire migration succeeded or that all files were recovered.

A different sequence of checks for the next migration

The following is a proposed brief derived from the failure. It is not a procedure whose effectiveness I have tested.

Inspect the files and the apps, sessions, and automation using their locations.
Compare candidate links for removal against current app settings and runtime use.
Separate copy-equality checks from checks that the original is healthy.
Include the file that first failed among the verification samples.
List unchecked files and workflows, and define the scope of completion precisely.

AI compared settings and records across multiple locations. Conditions omitted from those comparisons were also missing from its completion report. The correction is specific: deciding to delete a copy requires checking the health of the retained original alongside its hash; declaring a migration complete requires checking the applications that used the old location alongside the existence of the new folder.

This account brings together the requests and follow-up reports in the September 15, 2026 work session. Recovery results below are attributed to those reports; I did not repeat the original recovery tests while writing this article. Paths are illustrative.