## TL;DR
Treat the delta token as tied to the folder identity, not just the mailbox: when a folder is renamed or moved, expect the stored token to be rejected, fall back to a bounded resync of that folder only, and store the new token with the new folder ID atomically. Then add handling that distinguishes an expired or invalid token response from an empty result, so the agent logs a resync event instead of silently restarting a tenant wide sweep that burns hours and API quota.

```text
triage agent lost the graph delta token after a mailbox folder rename and rescanned from scratch
```

## Use this when
- The triage agent rescanned a mailbox from the beginning after a folder rename or move.
- Logs show a delta query error followed by a full enumeration of messages.
- The agent stores one delta token per mailbox rather than per folder.

## Not for this skill when
- The agent has no delta sync at all and always enumerates. That is a design task, not a token loss fault.
- Graph itself is throttling and the agent backs off correctly. That is rate handling working, not token loss.

## Steps
1. Reproduce the rename case in a test mailbox: sync a folder, rename it, then present the stored token and capture the exact Graph response. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: the invalid token response for a renamed folder is captured
2. Change token storage to key on the folder ID and to store the token and folder metadata in one write, so a crash cannot pair a new folder with an old token. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: the storage code shows the token written together with its folder ID
3. Add an explicit resync path for invalid token responses that resyncs only the affected folder and logs a named resync event. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: a forced invalid token in test produces a folder scoped resync and a log entry
4. Make any full mailbox rescan require an explicit flag or operator action, never an automatic fallback. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: the code path for a full rescan shows the flag check before it runs
5. Run the rename scenario again end to end and time the agent next sweep. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: the sweep after a rename completes in folder resync time, not full scan time

## Why it happens
Delta queries in Microsoft Graph track changes against a specific folder view. A rename or move changes that view, and tokens minted for the old view can be rejected or return misleading state. Agents written with a single mailbox level token and a silent fallback to full enumeration turn a cosmetic folder change into a full rescan, with the cost and duplicate triage that follow. The fault is in state handling, and it stays hidden until someone tidies a mailbox.

## Variants and edge cases
### triage agent lost graph delta token folder rename rescanned scratch
The exact state loss wording from agent logs.
### graph delta query token invalid after folder rename resync handling
The API behaviour variant.
### mail triage agent full rescan fallback invalid delta token fix
The fallback design variant naming the silent restart.

Compatibility: Microsoft Graph delta query for messages, agent state storage, folder ID semantics.

Edge cases to check:
- A resync after token loss should re-evaluate only new and changed items for triage, or the agent will re-report old phish as new incidents.
- Persist tokens in the same store as the agent checkpoint so restarts and renames are handled by one code path.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_JeYjIrjZ6ZsX2H2ttHsmxQ