Work safety
How Pathrule checks a risky edit before it lands, asks for confirmation when a write would collide with a teammate, and fails open so it never blocks your work.
The same hook that puts the right memories and rules in front of the assistant can also stop a bad write before it happens. Most tools tell you about a collision after you push and review. Pathrule checks for it before the file is written, while the assistant is still in the turn.
This page is about that check. For the mechanics of how hooks deliver context, read How hooks work. For the related but different guardrail that blocks a non-compliant change, read Rules as guardrails. This page covers the safety net that watches for risky edits to shared work.
A clean write does not ask. A risky one does.
Before the assistant writes a file, the hook runs a quick pre-tool check. If the file is clean, the check is silent and the write proceeds with no prompt. You see nothing.
A write is treated as risky in two cases:
- A teammate is actively working on the same file right now.
- A teammate has changed that file locally and has not committed it yet.
In either case the write surfaces as your AI client's normal confirmation moment, the same prompt you already see when an assistant asks before acting. There is no Pathrule modal, toast, or dashboard detour. The message names the person and the conflict, and nothing else:
Pathrule caught a possible conflict. Ahmet is actively working on this file. Continue?
Pathrule caught a possible conflict. Ahmet changed this file 3 days ago and has not committed it yet. Continue?
It does not mention setup, settings, health checks, or how the conflict was detected. It tells you who and what, then lets you decide.
Two different guardrails
It is worth separating this from rule enforcement, because they behave differently on purpose.
| Work-safety check | High-priority rule | |
|---|---|---|
| What it watches | Whether the file is being touched by a teammate or has their uncommitted changes | Whether the change violates a rule you marked for enforcement |
| What it does | Asks before the write, then lets you continue | Can block the write outright before the file is written |
| Why | Pathrule cannot prove intent across tools well enough to deny, so it warns | A violation here is a real regression you chose to wall off |
| You see | Your client's normal confirmation prompt | The rule text as the reason, so the assistant can retry inside the constraint |
The work-safety check asks. It does not hard-lock the file. A determined write can continue, because warning the human is the safer default when the system cannot be certain. The blocking behavior of an enforced rule is covered in Rules as guardrails.
Active work and uncommitted work expire differently
The two risky cases age out on their own terms.
- Active work is short-lived. Once a teammate stops touching the file, the active warning expires by itself.
- Uncommitted work is durable. If a teammate changed a file and walked away, the warning keeps appearing days later until that change is committed, reverted, or stashed. It clears on the next scan after the change is resolved, not on a timer.
This matters: the most common way one person silently overwrites another's work is editing a file the other person changed last week and never committed. That case does not expire, so it still asks.
Your own work never warns you
The check is about teammates, not you. Your own uncommitted changes do not trigger a warning, so on a personal workspace it stays quiet almost all the time. You only see a prompt when the file is in someone else's hands.
It fails open
A safety check that breaks your workflow when it breaks is worse than no check. This one fails open.
- If the check cannot verify in time, a write asks with a short degraded message and a read is allowed straight through. It never hangs the assistant waiting on a verdict.
- A degraded prompt is honest about what it could not do:
Pathrule could not verify teammate local state in time. Continue?
- One file turns every Pathrule hook off instantly, the same kill switch described in Rules as guardrails.
The check is a net under the work, not a gate in front of it.
Nothing leaves the machine that should not
The check works on path-level metadata about who is touching what file, not on the files themselves. Source code and diffs are never stored remotely. There is no setup, wizard, opt-in, or panel to monitor: if you have a normal Pathrule runtime installed, the check is already on, and it stays invisible until there is a real conflict.
It works the same across surfaces
A teammate on Desktop, on the CLI, or on Web paired to a local runtime all publish the same work state, and all see the same confirmation for the same conflict. Mixed teams are first-class: one person on Desktop and another on Web plus CLI get matching behavior. Browser-only Web with no paired local runtime cannot inspect local files, so it does not claim this coverage.
Verify it yourself
You do not have to take the behavior on faith.
To turn every Pathrule hook off instantly, including this check, create one file:
touch ~/.pathrule/kill-hooks
Remove it to turn hooks back on:
rm ~/.pathrule/kill-hooks
If you ever need to reset your own published work state, the CLI reconciles it from a fresh scan:
pathrule work-state reconcile
What to read next
- Rules as guardrails for the guardrail that blocks a non-compliant change outright.
- How hooks work for the delivery mechanics behind the check.
- Writing rules for marking a rule high priority for enforcement.
- MCP overview for the tool surface the assistant uses when it needs more.