[BUG] memory: field in subagent frontmatter not functional — reproduces on v2.1.137; tools allowlist appears to override auto-enable

Re-reporting the bug from #31294 (closed-as-inactive 2026-04-11 by github-actions bot, not because it was fixed). Reporter (@Mationetap) explicitly rejected the bot's suggested duplicates as not relevant. @gvelesandro is collecting reports of the same pattern at https://www.agentsneedcontext.com/agent-failure-postmortem.

This issue adds a new finding from a 5-agent reproduction: the explicit tools: allowlist appears to take precedence over the documented "memory: auto-enables Read/Write/Edit" behavior, which may be one of the mechanisms behind the bug.

Environment

• Claude Code: v2.1.137 (current)
• macOS Darwin 25.4.0
• 5 user-defined subagents with memory: configured (mix of user and project scopes)

Reproduction

5 subagents in ~/.claude/agents/, all with memory: field:

Telemetry shows 50+ invocations across these agents in the last 3 days with status:completed and no errors.

Two distinct subpatterns visible

Subpattern A — explicit tools: allowlist excludes Write/Edit (code-reviewer, design-lead)

Per the Anthropic subagent docs: "Read, Write, and Edit tools are automatically enabled so the subagent can manage its memory files."

This phrasing implies the auto-enable is additive. But agents whose explicit tools: allowlist excludes Write, Edit show no memory file creation. Suggests the allowlist takes precedence over the auto-enable, contradicting the documented behavior.

Test: I just added Write, Edit to the tools: field of code-reviewer and design-lead. Will report back whether memory accumulates after the next invocation.

Subpattern B — has Write/Edit but still doesn't write (dev-lead)

dev-lead has Read, Edit, Write, Glob, Grep, Bash, Agent in tools: and memory: user configured. Despite multiple invocations in the last 3 days (architecture reviews, multi-transport refactor, iOS popup), the directory ~/.claude/agent-memory/dev-lead/ remains empty. No MEMORY.md was ever created.

This matches the bug as @Mationetap originally reported it: the memory infrastructure simply doesn't activate for Task()-spawned subagents.

A plausible prompt-engineering contributor to this subpattern: dev-lead's memory section has elaborate Curate criteria ("Append only when X, Y, Z fires") that, combined with Opus 4.7's more-literal interpretation, may cause the agent to self-censor every potential write. Working agents (tdd-test-writer, docs-updater) have brief 2-line permissive memory sections. Need to test by simplifying the broken agents' memory sections — but this is a workaround, not a fix.

Why this matters

The persistent-memory feature shipped in v2.1.33 (Feb 2026) and is positioned as a primary value-add for subagent system design. Multiple users (including those producing 50+ daily invocations against memory-configured agents) cannot use it. Auto-closing as inactive doesn't reflect actual usage state — it reflects that frustrated users moved on to workarounds (external KB, manual file management).

Asks

1. Re-open #31294 or treat this as a fresh report
2. Confirm whether explicit tools: allowlist is intended to override memory: auto-enable (doc clarification needed regardless)
3. Investigate why Task()-spawned Opus subagents with proper tool access don't create MEMORY.md
4. Provide an officially-supported workaround until the root cause is fixed

Workaround currently being tested

Adding Write, Edit to all explicit tools: lists for memory-enabled subagents. Will edit this issue with results in 3-5 days of usage.

Filed by a Claude Code power user with 8 subagents + 59 skills + 6 active projects. Full background research and observability data in: 2026-04-17 claude-code-subagent-design-refresh.md, 2026-05-06 agent-prompt-engineering-techniques.md (private knowledge base, willing to share excerpts on request).