One of the most useful lessons in my setup guide is to test what the settings actually do.
A configuration can look reasonable while allowing more access than I intended. It can also block the project so completely that normal work fails.
I want to check both sides before giving the assistant important files. My storage move happens earlier; these checks decide whether the new AI workspace is ready.
I will first check the work account itself using harmless samples in personal folders, including folders I created directly under C: and their subfolders. I want to confirm that private files are blocked and the intended work folder remains usable. Mac and Linux users can test their own account permissions the same way.
The next test is positive. In a disposable project, can the assistant create and edit a harmless file? Can the project run with the intended restrictions still active? I will open the result myself.
The next tests check the limits. I can create a harmless sample file outside the allowed project and confirm that it exists. Then I can test whether the assistant’s file tool can read it and whether a command it runs can read it.
Those are different routes. Where the setup supports it, I also want a check using a small script that tries to open the same sample file. The important result is the actual access decision, not the assistant saying it thinks the file is unavailable.
An error saying the file does not exist is not proof that a permission rule blocked access. I need to understand why the attempt failed. Inside a container, I must also be sure I am checking the intended host location rather than an unrelated folder with the same name.
Other checks become relevant as I add tools. Does the secret scanner detect a documented fake test credential? Does a repository rule block the action it is meant to block? Does an approved cloud connection reach only the intended account or content?
I will use disposable files and repositories for these exercises, never real customer information or real keys.
My record can stay simple: date, tool version, expected result, actual result, and anything still untested.
Passing confirms those specific checks worked at that time. It does not prove the setup is safe against every possible problem.
For today, test one allowed action and one action that should be blocked. Write down what actually happened.