Cache local image summaries

[alfozan]

Problem

Repeated local image summary runs do not appear to use the summary cache. The same local image, prompt options, and model path can invoke the model again instead of returning a cached summary.

This is separate from #240 / #241. That issue/PR is about transcript cache keying for local audio/video extraction. This one is about summary caching for binary image attachments.

Repro

Use any local JPG/PNG and a CLI model path that makes repeated calls observable:

CODEX_PATH=/path/to/codex summarize ./fixture.jpg --length short --plain --verbose
CODEX_PATH=/path/to/codex summarize ./fixture.jpg --length short --plain --verbose

Expected:

• First run writes a summary cache entry.
• Second run reports or behaves as a summary cache hit.
• The model/provider is not invoked again for the identical local image and options.

Actual:

• The repeated run does not hit the summary cache.
• The image is summarized again.

Likely cause

The asset summary path gates summary cache reads/writes on both contentHash and promptHash:

• src/run/flows/asset/summary.ts computes contentHash = buildPromptContentHash({ prompt: promptText }).
• It only reads the summary cache when cacheStore && contentHash && promptHash.
• It only writes the summary cache under the same condition.

For image attachments, prepareAssetPrompt() builds a normal file summary prompt and attaches the image bytes separately. The prompt's <content> block is empty because the content is binary, not inline text. That makes buildPromptContentHash() return null, so the summary cache block is skipped entirely.

Relevant code paths:

• src/run/flows/asset/preprocess.ts, image attachments are passed as binary attachments.
• packages/core/src/prompts/file.ts, buildFileSummaryPrompt() uses content: "".
• src/cache-keys.ts, buildPromptContentHash() returns null for empty content.
• src/run/flows/asset/summary.ts, summary cache lookup/write require contentHash.

Suggested direction

For binary attachments, the summary cache needs a stable content identity that is not derived from inline prompt content. For local images, that could include a hash of the image bytes, or a file identity that includes the local file URL/path plus size/mtime. Byte hashing is likely more robust across path changes, while file metadata is cheaper but can miss same-content moves/copies.

The cache key should still include the existing prompt hash, model, length, language, and cache format version so prompt/options/model changes invalidate correctly.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 8, 2026, 3:33 AM ET / 07:33 UTC.

Summary
Keep open: current main still skips summary cache reads and writes for binary image attachments because image prompts have an empty content block and the asset summary cache path requires a non-null content hash. This is a narrow cache bug, separate from #240 and #241.

Reproducibility: yes. source inspection gives a high-confidence reproduction path: local images are binary attachments, their prompt content block is empty, and the asset summary cache is skipped when contentHash is null. I did not run the two-command CLI reproduction during this read-only review.

Next step
A single focused fix can add binary attachment content hashing for asset summary caching and targeted regression coverage without a product decision.

Review details

Best possible solution:

Add a binary attachment content identity, preferably a SHA-256 hash of the image bytes, to the asset summary cache key path and cover repeated local-image runs with a regression test.

Do we have a high-confidence way to reproduce the issue?

Yes, source inspection gives a high-confidence reproduction path: local images are binary attachments, their prompt content block is empty, and the asset summary cache is skipped when contentHash is null. I did not run the two-command CLI reproduction during this read-only review.

Is this the best way to solve the issue?

Yes, the narrow maintainable fix is to derive the asset summary contentHash from binary attachment bytes when prompt content is empty, while keeping the existing prompt/model/length/language invalidation behavior.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• I did not execute the CLI reproduction in this read-only pass; the bug is source-reproducible and should be locked down with a real cache-store regression test.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 769d01f0898f.

Label changes

Label changes:

• add P2: This is a normal-priority cache bug that can cause repeated model calls for local images but does not break core runtime availability.
• add impact:other: The issue has concrete user impact through unnecessary model invocations, latency, and cost for repeated local image summaries.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• add clawsweeper:queueable-fix: Current issue advisory state selects this label.
• add clawsweeper:fix-shape-clear: Current issue advisory state selects this label.

Label justifications:

• P2: This is a normal-priority cache bug that can cause repeated model calls for local images but does not break core runtime availability.
• impact:other: The issue has concrete user impact through unnecessary model invocations, latency, and cost for repeated local image summaries.

Evidence reviewed

Acceptance criteria:

• pnpm test tests/cache.keys.test.ts tests/cli.cache.summary.test.ts tests/asset.summary-branches.test.ts
• pnpm -s check

What I checked:

• Image attachments carry bytes outside prompt content: Local images are loaded as kind: "image" attachments with bytes, and prepareAssetPrompt() sends those bytes as an attachment rather than inline prompt content. (src/content/asset.ts:304, 769d01f0898f)
• File summary prompt has empty content block: buildFileSummaryPrompt() builds the tagged prompt with content: "", so binary image prompts do not provide content for the summary cache content hash. (packages/core/src/prompts/file.ts:90, 769d01f0898f)
• Empty prompt content returns no content hash: buildPromptContentHash() returns null when the extracted content block is empty or whitespace. (src/cache-keys.ts:45, 769d01f0898f)
• Asset summary cache is gated on contentHash: summarizeAsset() computes contentHash from the prompt text only, then checks and writes the summary cache only when both contentHash and promptHash are truthy. (src/run/flows/asset/summary.ts:459, 769d01f0898f)
• Cache contract expects summaries to avoid repeated work: The cache docs state the CLI summary cache exists to avoid repeated summaries and keys summaries by contentHash, promptHash, model, length, language, and format version. (docs/cache.md:37, 769d01f0898f)
• History points to the current cache/prompt implementation: Blame on the asset summary cache gate, content-hash helper, and empty file-prompt content traces those lines to release commit fcf8c8e by Peter Steinberger. (src/run/flows/asset/summary.ts:459, fcf8c8e5e98d)

Likely related people:

• steipete: Git blame attributes the current asset summary cache gate, empty binary file prompt content, and content-hash helper lines to release commit fcf8c8e by Peter Steinberger, and the repository shortlog shows broad ownership in this area. (role: feature-history owner; confidence: high; commits: fcf8c8e5e98d; files: src/run/flows/asset/summary.ts, src/cache-keys.ts, packages/core/src/prompts/file.ts)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.