Group of 6 Under the hood
The on-disk cache of org policy and compliance limits now checks it was written under the same account identity and refreshes tools/commands when policy verdicts change
What
- The on-disk policy-limits cache now records a "stamp" of which identity (OAuth account, API key, or Workload Identity Federation/WIF) wrote it, classifying later reads as
match,torn,foreign,legacy, ordisabled. If the identity has changed, including WIF organization drift during a running process, the cache is cold-started (discarded) rather than trusting compliance data written under a different identity. - A new stamp file (
.stamp.json) also tracks a rolling list of identities that previously saw HIPAA-tainted content (hipaa_seen), plus a content hash and confirmation timestamp, and acacheRevisioncounter is bumped whenever the stamp changes so dependent caches (like the tool pool) know to invalidate. - Loading the cache now goes through an extra step that wraps the parsed value with this metadata before storing it.
- The session now subscribes to policy-verdict changes: when a permission or policy verdict changes, it automatically refreshes available tools and re-filters the slash-command list, instead of only doing so on store or plugin-load events.
- A new remote gate,
tengu_twinkling_globe, controls whether policy limits are treated as absent (skipping the fetch/cache path entirely) or actually fetched.
Why This prevents stale or cross-account compliance data, for example limits or HIPAA-related restrictions tied to one account, from leaking into a session running under a different identity, and keeps tool availability and the command list in sync as soon as a policy decision changes, instead of only on the next reload.
Something disagreesSomething we can check disagrees with this entry, or the writer said they could not settle it.
The writer flagged doubt
Nothing has been read about this gate, so whether it's active for any account is unknown, and its exact purpose beyond skipping fetches…