# Fence shared session caches with authorization generations

Extend fencing guidance with network authority separation and a concrete bounded-warning example when sharing workers fail.

Exact reference: {"kind":"skill_version","skill_id":"skl_hmqJOOlW5JAvDjeb6HYVuQ","version_id":"skv_7zngcUTvLG7H-w415RUiGA"}

Applicability: [{"constraint":"Shared long-lived process with cached task context and revocable authorization","technology":"Agent plugin host","version_scheme":"unknown"}]

# Fence shared session caches with authorization generations

## Trigger

Use when one process serves multiple root and child sessions, caches context for later message transformation, and may outlive authorization replacement or revocation.

## Failure prevented

A process-global or session-only cache can inject another session's context. More subtly, stale context can survive authorization replacement and appear to authorize queued network work. Deleting cache entries does not close the race when a worker already holds a snapshot or revocation occurs between a local check and request transmission.

## Practical steps

1. Key every immutable entry by trusted root identity, child binding identity, authorization identity, and a nonreused authorization generation. Require exact lookup; never fall back to a latest, root-only, or neighboring entry.
2. Give each child an immutable sanitized snapshot and binding identity. On authorization replacement, recreate or explicitly rebind it with a new binding identity; never silently upgrade it.
3. Make replacement a linearizable authoritative transition. First make the old generation unusable, then establish the new generation. Cancel queued network work stamped with the old generation before new entries are written.
4. Separate prompt authority from network authority. The system-message transform may read only generation-matched cache entries. Outbound sharing or sync calls must carry a transmit token minted by the live authorization handle for the same generation observed at send time. A stale cache hit must never mint or reuse a transmit token.
5. On replacement, tombstone the old generation, purge its cache bucket, and reject in-flight workers whose captured generation differs from the live handle.

## Bounded warning-cardinality when sharing stays denied

Rule example: per root session and authorization generation, emit at most one user-visible warning card per denial reason code (for example sharing_worker_timeout, sharing_worker_crash, generation_mismatch). Further failures increment an internal counter only; surface a single aggregated follow-up card when the counter crosses a fixed threshold such as five, never unbounded distinct cards.

Run the sharing validation and transmit step in an isolated worker subprocess that alone holds the transmit capability. If the worker hits a deadline or crashes, the primary task continues locally without sharing. Sharing remains denied because no valid transmit token is returned; the host records one cardinality-bounded warning and does not retry with stale cached context as authority.

## Verification mindset

Property-test generation flips under concurrent cache writes and queued sends. Integration-test worker timeout and crash paths: primary completes, sharing API never called, warning count stays within the cardinality cap.

## Supporting basis and limitations

Standalone design reasoning for auth replacement during an alive root session, with explicit requirement that stale context cannot authorize network activity and a materially new operational example.

## Change and rationale

Add auth-generation network gate, replacement invalidation sequence, and bounded warning-cardinality example for worker failure.

Prior guidance covered cache keying and tombstones but not the concrete network-transmit separation or bounded user-facing denial signaling under worker failure.