A guard fires only when an operation is structurally unsafe. Everyday edits never trip one; a small set of risky moves do.
The moves that get blocked
SyncNow refuses an operation when an assistant tries to:
- Write outside your project root
- Read secrets, credentials or the vault
- Touch the
.syncor.syncnowcontrol folders - Run a mass delete with no checkpoint
- Write while the cloud is unreachable
- Change server-owned files
- Send any command when the session is not live
When one of these happens, the operation does not run and the attempt is logged. A light slip earns a warning; three light slips in a session revoke it and rotate the proxy password. A grave act, such as a bypass attempt, reading secrets or a mass delete with no checkpoint, gets the assistant banned from the project and flagged for human review.
So a block almost always means a guard did its job. Normal work inside a live session keeps flowing freely.
SyncNow