Bound CIMD cache growth

[jlowin]

CIMD clients are resolved from URL-shaped client IDs, but each distinct document was retained indefinitely in both the process cache and the persistent DCR registry. The assertion replay cache had the same failure mode: it enforced its capacity after insertion, so overload rejections still increased memory use.

Bound document retention with oldest-entry eviction, keep URL-derived clients out of persistent registration storage (while lazily removing legacy records), and enforce replay-cache capacity before inserting a new JTI.

if len(cache) >= max_size:
    cleanup_expired_entries()
    if len(cache) >= max_size:
        raise ValueError("Server overloaded, please retry")

cache[key] = value

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 4a34a5acd1

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Keep CIMD metadata available across proxy instances

When production uses shared client_storage across multiple workers—or a worker restarts—this returns a newly resolved CIMD client without persisting it, so the next authorization/consent/token request handled by another process must fetch the remote document again. If that origin is temporarily unavailable or rate-limited, an OAuth flow that already started fails despite the documented persistent client storage and the shared backend; although legacy records now survive failed refresh, newly resolved clients still have no fallback. Preserve a bounded/shared snapshot or otherwise retain the client for the duration of the flow.

AGENTS.md reference: AGENTS.md:L193-L195

Useful? React with 👍 / 👎.