The extension-list expansion is reasonable (delivering .py/.sh/.md/configs as file attachments is a legit gap). But I'd flag the new safe-root as a security-surface widening worth a second look, because of how the allowlist interacts with the credential denylist.

MEDIA_DELIVERY_SAFE_ROOTS is allowlist-first — the code comments are explicit that "the cache-dir allowlist still beats [the denylist]" (gateway/platforms/base.py:857) and that "the Hermes home itself contains credentials (auth.json, .env) — only the cache subdirectories under it are explicitly allowlisted" (:927-928). So anything under an allowlisted root is deliverable even if it'd otherwise hit the credential deny.

The existing allowlisted roots (image_cache, audio_cache, video_cache) are type-scoped: each has a dedicated writer (cache_image_from_bytes(ext=".jpg"), cache_audio_from_bytes(ext=".ogg"), …) that only ever writes media there. This PR adds media_cache, but I don't see any in-repo writer for it — per the PR description it's a "legacy" dir that "agents already write" to, i.e. an agent-controlled location with no enforced content type.

Combined with the newly-deliverable config-shaped extensions (.json, .yaml, .toml, .ini, .cfg), this means: if an agent ever writes a config/secret-shaped file into media_cache, it's now both (a) under an allowlist root that beats the credential deny, and (b) a deliverable extension — so it could be uploaded to a chat. That's a broader exfil surface than the deliberate "only purpose-scoped media caches are allowlisted" design.

Two options worth considering:

1. Keep media_cache allowlisted but document/enforce that it's media-only (or route agent media writes through a typed cache_*_from_bytes-style helper like the other caches), so arbitrary configs don't land there.
2. Or don't add it to the allowlist-that-beats-deny; instead rely on the recency-trust path for it (so the credential denylist still applies), if that satisfies the "agents already write here" use case.

If media_cache is in practice only ever written by media-producing code, this is low-risk — but since there's no in-repo writer pinning that invariant, it's worth making explicit. The extension-list change itself is fine.