# Session- and auth-bound task context cache

Bind in-process task-context caches to session epochs and live authorization generations, invalidate stale entries on replacement, separate prompt context from network authority, and enforce bounded retention.

Exact reference: {"kind":"skill_version","skill_id":"skl_wCKU3ytdp9mfmqZocBWzrA","version_id":"skv_dsRzgz0QPmoVpX2LCYFCEQ"}

Applicability: [{"constraint":"Any implementation with root and child sessions, cached transform context, and revocable or replaceable authorization","technology":"Shared-process agent plugins","version_scheme":"unknown"}]

# Session- and auth-bound task context cache

## Trigger

Use when an agent plugin caches task context before a system-message transform, multiple root or child sessions share one process, and authorization can be revoked or replaced while a root session remains alive.

## Failure this prevents

A process-wide or session-only cache can inject one session's context into another, retain context after authorization replacement, or let stale context authorize queued, retried, or background network work. Unbounded entries and retained callbacks can also exhaust memory.

## Practical steps

1. Use a canonical immutable key containing plugin instance, tenant or authorization lineage, root session, session epoch, live authorization generation, content revision, and explicit child binding. Include capability or policy scope when reuse could cross those boundaries. Use reserved root sentinels that real identifiers cannot produce.
2. Keep root and child entries separate. Inherit only through an explicit immutable snapshot; do not share mutable objects, buffers, request objects, closures, or full histories.
3. Read authorization state and its generation as one consistent snapshot. At every cache read, transform injection, and network operation, obtain live authorization state rather than trusting a generation captured across an await.
4. On revocation or replacement, atomically advance the generation, close and tombstone the old generation, cancel its queued and in-flight work where the transport supports it, and prevent old callbacks, retries, refreshes, redirects, streams, and follow-up calls from writing or dispatching.
5. Treat context as descriptive intent only. Enforce authorization at the network boundary with a defined linearization point or transport-level cancellation guarantee. Deny when authorization state is missing, stale, inconsistent, or changes before the operation's permitted dispatch point.
6. Remove entries on completion, failure, cancellation, timeout, epoch change, and shutdown. Ensure eviction and invalidation synchronize with readers and that closures and copied representations do not retain sensitive data.
7. Bound memory with per-entry and aggregate byte limits, entry-count limits, TTL or idle expiry, and LRU eviction. Count object overhead, copied strings and buffers, tombstones, queued work, and in-flight work. Reject oversized values explicitly.
8. Keep logs, errors, metrics, traces, serialization, timing, and size signals value-free where context may be sensitive. Fail closed during startup, restart, authorization-provider errors, and external authorization changes.

## Limits

A cache key does not replace authorization. Equality of identifiers is insufficient when authorization state can change or be reused; the live authorization source and consistency model must be authoritative. A pre-dispatch check alone cannot prevent a later revocation unless the network layer provides a cancellation or enforcement guarantee. Managed runtimes may retain immutable credential copies, so clearing sensitive material is best-effort unless storage is explicitly controllable. TTL and LRU alone are not hard memory bounds unless all retained work and representation overhead are included.

## Validation scenarios

Reason through concurrent roots, sibling and nested children, replacement during cache population and transform execution, queued dispatch, retries, redirects, streaming, background refresh, child inheritance, late callbacks, provider failure, eviction pressure, and cross-session lookup attempts. This guidance is based on reasoned analysis in the supporting discussion; no repository-specific inspection or executed tests support it.

## Supporting basis and limitations

The existing guidance already covers session epoch, authorization generation, and content revision. The supporting conversation identified the additional requirements: generation and authorization must be read consistently; invalidation must cover children and asynchronous work; cached context must never authorize network activity; and hard memory accounting must include retained work and copies. The review was standalone reasoned analysis, not repository inspection or executed tests.

## Change and rationale

Extend the existing cache guidance with live authorization-generation binding, consistent authorization snapshots, network-bound enforcement, revocation races, complete lifecycle coverage, and comprehensive memory accounting.

The existing skill matches the problem and is the exact current guidance to update. The new requirements add authorization replacement while the same root remains alive and incorporate the independent review's concrete race and retention findings without creating a duplicate skill.