Feature request: local-only and zero-retention modes for sensitive connectors such as Gmail

[Kaajot]

Summary

Please add a privacy-preserving mode for sensitive Codex connectors such as Gmail that can search, filter, and export data locally without sending source content to OpenAI, together with clear per-connector retention and metadata controls.

User-observed problem

I considered connecting a personal Gmail account so Codex could:

• search for messages matching task-related criteria;
• export selected emails or threads as PDFs;
• save those PDFs to a local directory for later review.

Before connecting the mailbox, I asked what would happen to the email content and metadata. The resulting privacy model was not clear enough to justify granting access:

• retrieved message bodies and associated metadata may need to pass through OpenAI systems for hosted-model processing;
• connector permissions govern whether tools may read or write, but do not themselves explain training, retention, operational logging, derived metadata, or deletion;
• disabling model training is not the same as a per-connector zero-retention guarantee;
• using a CLI, proxy, or tunnel does not solve the problem if source content still reaches a hosted model;
• a personal user may want a purely local search/export workflow without any hosted inference.

The practical result was that I declined to connect my personal mailbox.

Requested product behavior

1. Local-only connector execution

Provide a mode in which:

• Gmail authentication and retrieval occur locally;
• message search and rule-based filtering run locally;
• PDF generation and filesystem writes run locally;
• message bodies, headers, addresses, attachment contents, and identifiers are never sent to OpenAI;
• optional semantic processing uses a user-selected local model;
• the UI clearly indicates that the workflow is local-only.

2. Per-connector data controls

For each connected app, show and allow users to configure:

• whether source content may be sent to hosted models;
• whether content may be retained;
• whether metadata or derived metadata may be retained;
• whether content may be used for model improvement, safety analysis, or human review;
• the applicable deletion timeline;
• whether third-party subprocessors receive content;
• whether the connector is eligible for zero data retention.

These controls should be separate from read/write approval modes such as "Always ask" or "Allow low-risk actions."

3. Just-in-time disclosure

Before the first sensitive retrieval, show a concise disclosure specifying:

• what fields will leave the device;
• which systems will process them;
• what will be retained and for how long;
• which account-level and connector-level settings apply;
• whether continuing will place retrieved material into the Codex task history.

4. Data-minimizing hosted mode

When local-only processing is unavailable, support an intermediate mode that:

• performs exact search and filtering locally;
• redacts addresses and identifiers locally where possible;
• sends only the minimum selected excerpts to the hosted model;
• uses non-persistent processing where supported;
• produces a receipt describing what was transmitted.

5. Auditable deletion

Allow users to delete connector-derived content and associated metadata, with a receipt identifying the categories covered by deletion. This should address task content, cached connector results, derived summaries, identifiers, and relevant application state where deletion is supported.

Why this matters

Email is unusually sensitive. It can contain financial, medical, legal, employment, family, authentication, and third-party information. A broad mailbox connection also affects correspondents who never consented to having their messages processed by an AI provider.

Privacy and governance trust directly affect provider choice. Based on extensive reporting and conduct visible in the public record, some users have materially greater trust in Anthropic than in OpenAI. That assessment may lead them to choose Claude for cloud processing, even though a truly local workflow would be preferable to either provider. Concrete, inspectable privacy controls would be more persuasive than asking users to rely on institutional trust.

This is not a claim that another cloud provider offers local processing or guarantees zero retention. It is a report that the current trust and control model can prevent privacy-conscious users from adopting Codex connectors.

Suggested acceptance criteria

1. A user can select Local only before connecting Gmail.
2. In local-only mode, network inspection confirms that email content and email-derived metadata are not transmitted to OpenAI.
3. Codex can search locally and create local PDFs without exposing source messages to the hosted model.
4. Each connector displays content, metadata, retention, training, safety-review, and deletion behavior separately.
5. Sensitive retrieval requires a clear first-use disclosure and explicit consent.
6. Hosted processing can be limited to user-selected, minimized excerpts.
7. Users can review a transmission receipt showing which categories of data left the device.
8. Users can delete connector-derived task content and supported associated metadata.
9. Documentation explains the distinction between tool permissions, model training, task history, application state, abuse/safety logs, and operational metadata.

Privacy note

No email contents, addresses, message identifiers, account details, or private correspondence are included in this report.