[cache-strategy] Fix cache miss in Smoke Codex

[github-actions]

Cache Strategy Problem: Smoke Codex

Severity: High

Workflow: Smoke Codex
Analysis Date: 2026-05-01
Issue Type: Cache miss

---

Problem Description

The workflow declared cache-memory and restored with a run-specific cache key plus a restore-key fallback, which is the expected last-write-wins pattern. In the analyzed run, the restore still missed, so the workflow started cold and repeated work that cache-memory is intended to avoid.

Evidence

• Miss streak: 1 analyzed cache-memory run
• Miss rate (14d): 100%
• Last cache hit: never
• Log signals: workflow-logs/4_agent.txt: Cache not found for input keys: memory-none-nopolicy-smokecodex-25203411968, memory-none-nopolicy-smokecodex-

Cache Key Context

The observed run used cache key memory-none-nopolicy-smokecodex-25203411968 and restore key memory-none-nopolicy-smokecodex-. Because a restore-key fallback exists, this is not flagged as a volatile-key misconfiguration. The issue is a cold restore/no reusable prior cache state in the analyzed window.

Recommended Fix

1. Persist meaningful state - Verify the workflow writes meaningful files under /tmp/gh-aw/cache-memory/ before the upload step. The key has a restore-key fallback, so the cold start is not caused by an invalid volatile key; the next fix target is ensuring useful state is persisted and available to later runs.
2. Add lightweight validation - Log the cache directory contents before upload and after restore so future runs can distinguish a true cold start from an empty or write-only cache.
3. Track hit history - Record the last successful cache read in a small JSON file under the workflow's cache-memory directory.

Expected Impact

Fixing the cache strategy should reduce repeated setup and analysis work in future Smoke Codex runs, especially for scheduled or smoke workflows that run frequently.

References: §25203588394, §25203411968

Warning

Firewall blocked 4 domains

The following domains were blocked by the firewall during workflow execution:

• ab.chatgpt.com
• api.github.com
• chatgpt.com
• github.com

💡 Tip: api.github.com is blocked because GitHub API access uses the built-in GitHub tools by default. Instead of adding api.github.com to network.allowed, use tools.github.mode: gh-proxy for direct pre-authenticated GitHub CLI access without requiring network access to api.github.com:

tools:
  github:
    mode: gh-proxy

See GitHub Tools for more information on gh-proxy mode.

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "ab.chatgpt.com"
    - "api.github.com"
    - "chatgpt.com"
    - "github.com"

See Network Configuration for more information.

Generated by Daily Cache Strategy Analyzer · ◷

• expires on May 8, 2026, 5:39 AM UTC