ChatGPT code reveals permanent email addresses for dots and fixed work-account handles

RUNTIMEWIRE INVESTIGATION — Original analysis

Original reporting by RuntimeWire, based on reverse engineering.

Reporting record

OpenAI is building a native email-address setup flow for ChatGPT dots, with permanent personal handles, fixed work-account addresses and controls for activating email under the agent’s existing permissions, according to code RuntimeWire found in the official Windows app.

The implementation goes beyond the email-suffix references reported before dots launched. It includes address options supplied by a server, a claim request, a link between an address and a particular dot, sending-consent handling, and interfaces for disconnecting and reconnecting an owned address. RuntimeWire has not confirmed that the flow is available to ordinary accounts, claimed an address or sent a message through it.

OpenAI’s getting-started guide, checked on October 7, says users can connect a personal email account, while standalone addresses for dots are unavailable at launch. A separate privacy FAQ refers to a dot having its own email or Slack account. That broader wording does not document this native address-claiming workflow or establish who can use it.

Email identities were already part of the public discussion. TestingCatalog reported an “-o” email suffix on September 26, and RuntimeWire credited that finding in its September 28 preview. AgentMail has also published instructions for giving a dot an inbox through its service. The finding here is OpenAI’s own claim-and-management implementation and the rules it applies to those addresses.

For a personal address, the client accepts a handle of one to 30 lowercase letters, digits, hyphens or dots. Dots cannot appear at the beginning or end or occur consecutively. The submit handler trims and lowercases the entry, and the code’s field description says no suffix is added to a personal handle. The domain comes from the server; the client uses its default only when that domain also appears in the returned list of available domains.

One standalone dialog warns: “This email is permanent and cannot be edited.” That warning is specific to a new personal claim. The same component has an embedded setup presentation that does not render the warning in the inspected branch. The bundle therefore supports the permanence rule while leaving questions about how consistently it would be presented in a released interface.

Work-account handling follows a separate path. The component recognizes workspace subdomains under chatgpt.email, with staging and testing variants, and also supports an explicit server flag for automatic work-address allocation. It can use a suggested address or an existing claim. A fallback derives the local part from the employee’s login alias and appends “-dot.” The interface presents work addresses as fixed and tells users they cannot customize them.

Those rules do not identify a live domain available to a particular customer. RuntimeWire did not obtain an eligible server response, and the pattern in the client does not establish custom-domain support or a public allocation policy.

Claiming and sending activation are connected in the client. Claim and link requests record consent version 1. An already linked address without the expected consent can show an “Enable email sending” action. Other states offer an activation step or a setup-repair action. The interface descriptions say activation operates under the dot’s normal permissions; the code does not establish unrestricted outbound mail, recipient rules, sending limits or delivery reliability.

The profile’s linked-address menu includes actions to copy the address, open the user’s mail app with the dot as recipient, and remove the link. The removal description says ownership of the address remains with the user. This control exists outside the debug-only address picker. The debug interface separately supports selecting an owned, unlinked address and repairing setup. Neither interface establishes that a removed address returns to a public pool.

Several checks stand between the bundled interface and a working account. A feature gate controls the email contact entry. Setup requires an active cloud dot; local and archived assistants receive a disabled control. The server supplies email enablement and address options, and the client handles workspace-admin blocks, ineligible accounts, unavailable addresses, quotas and missing sending permission. The existence of those error states does not reveal actual limits or which plans will qualify.

RuntimeWire prepared a labeled reconstruction of the personal-claim and work-activation dialogs using the component’s copy, branch logic and control order. Its addresses are fictional and its styling is approximate. The images show how the code organizes those states; they are not screenshots of an activated feature.

The client provides strong evidence of a native email setup workflow under development. OpenAI’s intended rollout, retention policy after account deletion, ownership-transfer rules and the scope of permitted sending remain unconfirmed.