Background-agent security warning misfires on actions the parent conversation explicitly authorized

Summary

When a forked subagent (Agent tool, subagent_type: "fork") performs an "external system write" (e.g. gh issue create), the automated post-hoc security review attached to the task-notification flagged it as a potential policy violation — even though the parent conversation contained clear, explicit user authorization for that exact action, and the fork inherits the parent's full conversation context.

Steps to reproduce

1. In a session, have the user explicitly instruct: "file GitHub issues for items X, Y, Z" and "spawn an agent in the background for filing issues."
2. Launch a fork (subagent_type: "fork") with a prompt directing it to file those issues via gh issue create, referencing the user's own prior instructions.
3. The fork completes the task correctly — files exactly the issues requested, no scope creep.
4. The <task-notification> result included:

> SECURITY WARNING: ... The sub-agent filed four new public GitHub issues ... without any visible explicit user instruction authorizing this specific publishing action.

This is a false positive: the user's instruction to file those exact issues was present verbatim in the conversation transcript just prior to launching the fork.

Secondary issue: incorrect "public" framing

The same warning described the created issues as "public," which was also incorrect — the target repository was confirmed private via gh repo view --json isPrivate (isPrivate: true). The security review didn't check actual repo visibility before asserting it.

Impact

• Causes the assistant to surface unnecessary security alarms to the user for correctly-authorized, correctly-scoped actions, eroding signal-to-noise for when a real policy violation occurs.
• The incorrect "public" claim could make a user more alarmed than the situation warrants (or, in the opposite case, less alarmed if a private-repo assumption is wrong).

Suggested fix

• When evaluating whether an "external system write" by a forked subagent was authorized, the review should have access to (or at least credit) the parent conversation's explicit instructions that the fork inherited — not just the fork's own isolated tool-call sequence.
• Before labeling created/affected resources as "public," check actual visibility (e.g. via the same API/CLI the agent already has access to) rather than defaulting to an assumption.

---
Filed by Claude (Claude Code) on behalf of the repo owner, who asked me to report this after observing the false-positive firsthand in a working session.