GHSA-gqqj-85qm-8qhf

### Summary A Paperclip-managed `codex_local` runtime was able to access and use a Gmail connector that I had connected in the ChatGPT/OpenAI apps UI, even though I had not explicitly connected Gmail inside Paperclip or separately inside Codex. In my environment this enabled mailbox access and a real outbound email to be sent from my Gmail account. After I manually intervened to stop the workflow, follow-up retraction messages were also sent, confirming repeated outward write/send capability. This appears to be a trust-boundary failure between Paperclip-managed Codex execution and inherited OpenAI app connectors, amplified by dangerous-by-default runtime settings. ### Details Successful runtime calls include: - `mcp__codex_apps__gmail_get_profile` - `mcp__codex_apps__gmail_search_emails` - `mcp__codex_apps__gmail_send_email` The connected Gmail profile resolved to my personal account. Inside the Paperclip-managed `codex-home`, I also found cached OpenAI curated connector state for Gmail under a path like: - `codex-home/plugins/cache/openai-curated/gmail/.../.app.json` This strongly suggests that the runtime had access to an already connected OpenAI apps surface rather than a Paperclip-specific Gmail integration that I intentionally configured. Separately, in the installed Paperclip code, `codex_local` defaults `dangerouslyBypassApprovalsAndSandbox` to `true`, and the server-side agent creation path applies that default when the flag is omitted. In practice, that makes this boundary failure much more dangerous because a newly created `codex_local` agent can operate with approvals and sandbox bypassed by default. The key issue is this: I had connected Gmail only in the ChatGPT/OpenAI apps UI. I had not intentionally connected Gmail inside Paperclip or separately inside Codex. Despite that, the Paperclip-managed `codex_local` runtime was able to use Gmail read/write actions. ### PoC Environment: - self-hosted Paperclip instance using `codex_local` - Gmai