Changelog

Organization invitations could be used as an open relay: any signed-in account could create an Organization and make the app mail any address, with the Organization name as the subject. The subject is now a constant built from the product name, and the inviter's and Organization's names appear in the body as attributed plain text (Name (verified address) invited you to join the organization "…"), HTML-escaped, length-capped and with link-shaped tokens defanged so no client auto-links them. Every template applies the same treatment to names, and the security notice prints a readable UTC timestamp (Email, commit e951425).

Sending now requires a verified inviter email even when AUTH_SKIP_EMAIL_VERIFICATION is true, and is limited to 20 invitations per inviter and 50 per Organization per rolling day, 50 pending invitations per Organization, and 10 invite-member requests per 10 minutes per client IP. The default owner, admin and member roles are written down in the plugin configuration. Refusals are typed codes translated in en, de and fr (Authentication and Organizations, commit 88e8671). The web invite dialog and the mobile invite group show the verify-your-email state with a button that sends the verification email (commit b9e63fd).

EMAIL_REPLY_TO sets a Reply-To on every message through the Worker binding, Cloudflare REST and Resend, and the product name every email prints comes from EMAIL_FROM's display name; the hard-coded fallback is gone. The email guide documents the SPF, DKIM and DMARC records the sending domain needs for either provider (commit 8f90bc5).

The todo_list widget now renders in hosts that follow the MCP Apps specification. The view performs the ui/initialize → ui/notifications/initialized handshake the specification requires before a host may send tool data, then renders ui/notifications/tool-result; it keeps reading window.openai.toolOutput for ChatGPT builds that still inject it. There is one resource, ui://widget/todos/v2 with text/html;profile=mcp-app and an explicit empty CSP; openai/outputTemplate is the ChatGPT alias of _meta.ui.resourceUri and points at the same URI, so the text/html+skybridge duplicate is gone. A jsdom harness plays the host side in the test suite.

The MCP server says what it is. initialize names it after the OAuth issuer host instead of the template, returns instructions that summarize the approval flow, and declares listChanged: false for tools, resources and prompts, since a server built per request never notifies. Every tool sets all four annotations (reads are read-only and idempotent; nothing is destructive or open-world) and write tools publish the approval envelope as their outputSchema.

Agents can follow an approval to its end. A write call returns an absolute approvalUrl, /integrations?approval=<id> on the deployment that served it, which opens Integrations on that record. The new read-only approval_status tool reports whether the user executed (with the stored result), denied or let the request expire; the catalog has sixteen tools. The OAuth provider offers the email scope so UserInfo returns email and email_verified, and /.well-known/openai-apps-challenge serves the OPENAI_APPS_CHALLENGE_TOKEN Worker var during an OpenAI plugin review (404 while unset).

The agent plugin package is installable again. The Cursor and Grok marketplaces pointed at a folder that had been renamed, every manifest used the workers.dev origin instead of the production domain, and plugin.json carried a top-level logo the Agent Plugins 1.0.0 schema rejects. Listing copy and logo moved under extensions["com.openai"].interface, mcp.json declares the OAuth client, and new .claude-plugin/marketplace.json and .agents/plugins/marketplace.json files make it installable from Claude Code, the ChatGPT desktop app and Codex. The connection guide describes ChatGPT's current path, chatgpt.com/plugins → + → Add custom MCP server.

• MCP and agent connections
• Connect your agent
• ADR-0007

Sources: widget and server, approval status, challenge route and email scope, plugin marketplaces.

The landing, privacy, terms, posts and profiles exist once per language at one path each: the default language at the clean URL, the others under their slug (/privacy, /de/privacy, /fr/privacy). Each is its own indexable page with a self canonical, hreflang for every language plus x-default, og:locale, <html lang> and a share image in its language; share links carry their language without a query. The route files are not duplicated: they moved under routes/{-$locale}/, TanStack Router's optional segment (SEO and discovery, commit).

The languages, their URL slugs and optional translated segments are one leaf, packages/intl/src/locale.config.ts; a project maps pt-BR to /br there, and the pure path functions in locale-paths.ts (split, localize, canonical form, region-tag matching for ?lang= and Accept-Language) read it. getSSRLanguage takes the language from the path on public pages and from the cookie everywhere else (Internationalization, commit).

The old URLs keep working: ?lang=de, a region tag (?lang=de-DE, ?lang=de_AT), /en/privacy and /DE/privacy answer a 301 to the path form with the rest of the query kept; an unknown language goes to the default page. A first human visit to / follows the locale cookie, then Accept-Language, with a 302 and Vary: Accept-Language, Cookie; crawlers, requests without Accept-Language, prefixed URLs and POST are never redirected (rootLocaleRedirect in the config). The language switcher on public pages is a list of links to the current page in each language and remembers the choice in the cookie; the header, footer, legal links and consent banner link within the page's language, and links to sign-in and the app stay unprefixed. The Markdown copies follow the same paths (/de/privacy.md; Accept: text/markdown on /de returns /de/index.md), the sitemap lists every language's URL with xhtml:link alternates and llms.txt names the per-language documents (Agent-readable pages).