Multi Email

Multi Email ist ein Open-Source-Codex-Plugin und MCP-Server für unabhängig autorisierte Gmail- und Microsoft-365-Postfächer. Jede Operation benennt einen expliziten account_alias; es gibt kein implizites aktives Postfach.

Es unterstützt Suchen, Lesen, Entwerfen, Archivieren, Änderungen des Lesestatus, Gmail-Labels, Microsoft-Kategorien und das Senden über ein servererzwungenes localhost-Überprüfungsfenster.

Versionsstatus: 0.1.2 ist nur offiziell, wenn es aus dem annotierten Tag v0.1.2 oder dem passenden GitHub-Release unter lanfuli/multi-email installiert wird. Das npm-Paket codex-multi-email ist noch nicht veröffentlicht; überprüfen Sie den Repository-Besitzer und das Release-Tag vor der Installation.

Warum es das gibt

Die meisten E-Mail-Integrationen gehen von einem aktiven Konto aus. Multi Email hält das Routing explizit, sodass eine Anfrage mehrere unabhängig autorisierte Konten abdecken kann, ohne Nachrichten-IDs, Entwürfe, Labels oder Anmeldedaten zu vermischen.

Codex task
  -> Multi Email skill and MCP tools
  -> local Node.js MCP process
  -> Gmail API or Microsoft Graph

OAuth tokens -> macOS Keychain
Account aliases and OAuth app settings -> local mode-0600 config
Mailbox content returned by tools -> Codex conversation/model context

Der MCP-Prozess und der Anmeldedatenspeicher laufen auf dem Mac, aber der End-to-End-Workflow ist nicht unbedingt nur lokal. Prompts und Tool-Ergebnisse, einschließlich ausgewählter E-Mail-Inhalte, können gemäß den Produkt-, Konto- und Datenkontroll-Einstellungen des Benutzers von Codex/OpenAI verarbeitet werden. Google und Microsoft verarbeiten auch Provider-API-Datenverkehr. Siehe Sicherheit, Datenschutz und Datenfluss.

Related MCP server: Gmail MCP Server

Sicherheitsmodell

• Jede Operation erfordert einen expliziten account_alias.

• Lesen ist die Standardfähigkeit; Mutationen erfordern eine aktuelle, explizite Benutzeranfrage.

• Dauerhaftes Löschen ist nicht verfügbar.

• E-Mail-Inhalte, Anhänge, zitierter Text, Signaturen und Links werden als nicht vertrauenswürdige Daten behandelt, niemals als Tool-Anweisungen.

• Such-, Schreib-Batch-, Empfänger- und Textgrößen sind begrenzt.

• Das Senden ist blockiert, bis der Benutzer den vollständigen unterstützten Klartext-Entwurf in einem 127.0.0.1-Fenster überprüft und auf „Genehmigen“ klickt.

• Eine kurzlebige approval_request_id ist an ein effektives Sende-Manifest gebunden: authentifizierter Prinzipal, Postfach, effektive Absenderidentität, Entwurfs- und Thread-Identität, jeder Empfänger, Betreff, vollständiger Text, Provider-Revision und das verifizierte Fehlen von Anhängen. Die Genehmigung läuft ab, ist nur einmal verwendbar und wird durch jede gebundene Änderung ungültig.

• Version 0.1.2 schlägt vor der Überprüfung oder dem Senden fehl, wenn ein Provider-Entwurf HTML, mehrteilige oder unbekannte MIME, Inline-Inhalte, Anhänge, eine fehlerhafte Postfachadresse, eine nicht unterstützte From/Sender/Reply-To-Identität oder eine unvollständige Provider-Revision enthält.

• Die Provider-Sendeanfrage wird aus den genehmigten, auf die Whitelist gesetzten Klartextfeldern erstellt. Gmail liefert diese eingefrorene Roh-Nachricht in der Entwurfs-Sendeanfrage; Microsoft verwendet eine MIME-sendMail-Anfrage, anstatt einen veränderbaren Provider-Entwurf zu senden.

• Kein MCP-Tool kann seine eigene Sendeanfrage genehmigen.

• Ein Senden wird nach einem mehrdeutigen Ergebnis nie automatisch wiederholt, da der Provider es möglicherweise bereits akzeptiert hat.

Diese Kontrollen reduzieren versehentliche und prompt-injizierte Aktionen; sie machen OAuth-Tokens nicht schreibgeschützt. Google gmail.modify und Microsoft Mail.ReadWrite plus Mail.Send gewähren erheblichen Postfachzugriff.

Unterstützte Operationen

Das Plugin ruft absichtlich keine Provider-Endpunkte für Anhangsinhalte auf, legt Anhangsinhalte nicht über MCP offen, löscht keine E-Mails dauerhaft, verwaltet keine Kalender, legt keine beliebigen Provider-APIs offen und aktiviert nicht automatisch Send-as-Aliase, delegierte Identitäten oder freigegebene Postfächer. Gmail-format=full-Antworten können dennoch kleine Inline-MIME-Part-Bytes an den lokalen Prozess liefern; sie werden nicht vom Tool zurückgegeben. Nachrichtenlesen legt nur Anhangsnamen offen. Vom Plugin erstellte Entwürfe sind Klartext. Provider-Entwürfe mit HTML, Inline-Inhalten, Anhängen, fehlerhaften Postfachadressen oder nicht unterstützten Identitäten können das Sendeüberprüfungs-Gate in Version 0.1.2 nicht passieren.

Suchanfragen sind providernativ: Gmail-Suchsyntax für Google und Microsoft-Graph-Mail-Suchsyntax für Microsoft 365.

mail_list_accounts meldet, ob ein lokaler Anmeldedatensatz mit credentialPresent und connectionStatus (credential_present_unverified oder not_authorized) vorhanden ist. Diese Felder sind keine Authentifizierungsansprüche. Verwenden Sie mail_diagnose_accounts, um die aktuelle Token-, Bereichs- und Provider-Identitätsgesundheit zu überprüfen.

Anforderungen

• macOS auf Apple Silicon oder Intel

• Node.js 22 oder neuer

• Codex-Desktop oder CLI mit lokalem stdio-MCP- und Plugin-Support

• Ein Google-Cloud-Desktop-OAuth-Client mit aktivierter Gmail-API für Gmail-Konten

• Eine Microsoft-Entra-Public-Client-Anwendung für Microsoft-365-Konten

Das eingecheckte dist/-Bundle enthält seine JavaScript-Abhängigkeiten und beide nativen macOS-Keychain-Binärdateien, sodass ein Git-Marketplace-Snapshot ohne ein eingechecktes node_modules/-Verzeichnis starten kann. Entwicklungs- und npm-Bibliotheksimporte verwenden weiterhin normale npm-Abhängigkeiten.

Von GitHub installieren

Die transparenteste Installation ist ein lokaler Klon:

git clone https://github.com/lanfuli/multi-email.git
cd multi-email
git checkout --detach v0.1.2
node ./scripts/multi-email --help
codex plugin marketplace add "$(pwd)"
codex plugin add multi-email@multi-email

Starten Sie nach der Installation eine neue Codex-Aufgabe, damit die Fähigkeit und die MCP-Tools erkannt werden.

Codex akzeptiert auch eine Git-Marketplace-Quelle, sobald das Repository existiert:

codex plugin marketplace add lanfuli/multi-email --ref v0.1.2
codex plugin add multi-email@multi-email

Das explizite --ref hält den installierten Snapshot auf dem überprüften Release statt auf dem sich bewegenden Standardzweig. Der Repository-Marketplace-Eintrag verwendet die dokumentierte lokale Quelle im Repository-Stammverzeichnis ("./"). Das aktuell dokumentierte Codex-Marketplace-Schema hat auch URL-, Git-Unterverzeichnis- und npm-Quellenformen; dieses Repository verwendet keine npm-Quelle, da keine npm-Veröffentlichung stattgefunden hat.

Die Setup-Beispiele unten laufen aus dem passenden lokalen Klon. Eine zukünftige npm-Installation kann das äquivalente multi-email ...-Binär direkt verwenden; führen Sie npm run setup nicht aus einem verbrauchenden Projekt aus.

OAuth konfigurieren

Der Standardkonfigurationspfad ist:

~/.config/codex-multi-email/config.json

Setzen Sie CODEX_MULTI_EMAIL_CONFIG, um einen anderen absoluten Pfad zu verwenden. Die Setup-CLI erstellt ein fehlendes Konfigurationsverzeichnis mit Modus 0700, lässt die Berechtigungen eines vorhandenen übergeordneten Verzeichnisses unverändert, schreibt die Konfigurationsdatei mit Modus 0600 und lehnt ein Konfigurationsziel ab, das ein Symlink oder eine nicht reguläre Datei ist.

Initialisieren Sie entweder einen Provider unabhängig oder geben Sie beide Provider-Einstellungen in einem Befehl an.

Nur Google:

node ./scripts/multi-email init \
  --google-client-json /absolute/path/to/desktop-oauth.json

Nur Microsoft:

node ./scripts/multi-email init \
  --microsoft-client-id <entra-application-client-id> \
  --microsoft-tenant organizations

Beide Provider:

node ./scripts/multi-email init \
  --google-client-json /absolute/path/to/desktop-oauth.json \
  --microsoft-client-id <entra-application-client-id> \
  --microsoft-tenant organizations

Um Microsoft-Einstellungen später hinzuzufügen oder zu ersetzen:

node ./scripts/multi-email set-microsoft-client <entra-application-client-id> \
  --microsoft-tenant organizations

Fügen Sie jedes Postfach unabhängig hinzu und autorisieren Sie es:

node ./scripts/multi-email add-account gmail-01 <gmail-address> google
node ./scripts/multi-email auth gmail-01

node ./scripts/multi-email add-account m365-main <microsoft-365-address> microsoft
node ./scripts/multi-email auth m365-main

node ./scripts/multi-email list
node ./scripts/multi-email doctor

Verwenden Sie Platzhalter nur in der Dokumentation; committen Sie keine echten Adressen, OAuth-Client-JSON, generierte Konfiguration, Autorisierungs-URLs, Codes oder Tokens.

Google OAuth

Google-Autorisierung fordert openid, email und gmail.modify über einen Loopback-Desktop-OAuth-Flow an. Das zurückgegebene Gmail-Profil muss genau mit der konfigurierten Adresse übereinstimmen, bevor Tokens im Keychain gespeichert werden.

Bring-your-own-OAuth-Anmeldedaten befreien eine App oder einen Benutzer nicht von Googles Verifizierungs-, Zustimmungsbildschirm-, Testbenutzer-, eingeschränkten Bereichs-, Organisations-, Kontingent- oder Aufbewahrungsanforderungen. Ein OAuth-Projekt im Testmodus kann sich anders verhalten als eine verifizierte Produktions-App, und einzelne Konten oder Administratoren können den Zugriff weiterhin blockieren.

Microsoft OAuth

Microsoft-Autorisierung verwendet die interaktive MSAL-Systembrowser-Autorisierung und fordert delegierte User.Read, Mail.ReadWrite und Mail.Send an. Das /me-Profil muss mit der konfigurierten Identität übereinstimmen, bevor der MSAL-Cache gespeichert wird. Mandantenrichtlinie oder Administratorzustimmung können diese Bereiche blockieren.

In Codex verwenden

Nennen Sie immer den Kontoalias:

• „Verwenden Sie gmail-01, um ungelesene Nachrichten der letzten zwei Tage zu finden.“

• „Fassen Sie über gmail-01 und m365-main Nachrichten zusammen, die meine Antwort benötigen, ohne Änderungen vorzunehmen.“

• „Erstellen Sie einen Antwortentwurf in m365-main; senden Sie ihn nicht.“

• „Diagnostizieren Sie alle konfigurierten Konten, ohne E-Mails zu lesen oder zu ändern.“

Für ein Senden:

1. Bitten Sie Codex, den ausgewählten Entwurf zur Überprüfung vorzubereiten.

2. Überprüfen Sie die authentifizierte Identität, effektive From/Sender/Reply-To, jeden Empfänger, Betreff, Threading-Header, Format, Anhangsstatus und den vollständigen Klartext im localhost-Fenster, das vom MCP-Server geöffnet wird.

3. Klicken Sie in diesem Fenster auf „Genehmigen“ oder „Ablehnen“.

4. Kehren Sie zu Codex zurück und bestätigen Sie explizit, dass die lokale Überprüfung abgeschlossen ist.

5. Der Server erstellt das effektive Sende-Manifest neu, verbraucht die einmalige Genehmigung, überprüft die Provider-Revision erneut und friert die genehmigten Whitelist-Felder in eine Sendeanfrage ein.

6. Ein eingefrorenes Microsoft-Senden behält absichtlich den ursprünglichen Quellentwurf bei, da die Graph-Aktion zum Senden eines vorhandenen Entwurfs keine bedingte Revisionssperre hat. Überprüfen Sie das Ergebnisfeld sourceDraftRetained; senden Sie diesen beibehaltenen Entwurf nicht erneut ohne eine neue Überprüfung.

Fügen Sie die lokale Überprüfungs-URL, Cookies, Nonces, Fingerabdrücke, OAuth-Werte oder Keychain-Inhalte nicht in Codex oder ein Issue ein.

Aktualisieren

Für einen lokalen Klon-Marketplace:

git fetch origin --tags
git checkout --detach v0.1.2
codex plugin add multi-email@multi-email

Ersetzen Sie v0.1.2 nur mit einem neueren annotierten Release-Tag, den Sie überprüft haben. Ein Git-Marketplace, der mit --ref installiert wurde, bleibt gepinnt, also verschieben Sie ihn explizit auf ein neues Release:

codex plugin remove multi-email@multi-email
codex plugin marketplace remove multi-email
codex plugin marketplace add lanfuli/multi-email --ref v0.1.2
codex plugin add multi-email@multi-email

Starten Sie nach der Neuinstallation eine neue Codex-Aufgabe.

Deinstallieren und lokale Daten entfernen

Entfernen Sie das Plugin und den Marketplace:

codex plugin remove multi-email@multi-email
codex plugin marketplace remove multi-email

Die Plugin-Entfernung löscht keine OAuth-Anmeldedaten oder Konfiguration. Bevorzugen Sie die geschützten Lebenszyklusbefehle, bevor Sie den Klon löschen:

node ./scripts/multi-email logout <alias> --confirm
node ./scripts/multi-email revoke <alias> --confirm

logout entfernt lokale Anmeldedaten. revoke versucht auch eine provider-seitige Widerrufung, wo der Provider dies sicher unterstützt; Microsoft kann eine Entfernung über Microsoft My Apps gefolgt von logout erfordern. Überprüfen Sie das Befehlsergebnis, anstatt anzunehmen, dass der Provider-Widerruf erfolgreich war.

Aktuelle Keychain-Elemente verwenden den Dienst io.github.lanfuli.multi-email. Historische Installationen können auch verifizierte Legacy-Elemente unter com.openai.codex.multi-email haben; der Anmeldedatenspeicher migriert nur nach Validierung der Provider-Identität, während doctor bewusst schreibgeschützt ist und nie migriert. Verwenden Sie macOS-Schlüsselbundzugriff für optionale Legacy-Bereinigung und überprüfen Sie den genauen Konfigurationspfad, bevor Sie ~/.config/codex-multi-email/config.json löschen.

Entwicklung

npm ci
npm run validate
npm run pack:check
npm audit --omit=dev --audit-level=high

npm run build verwendet die exakte @vercel/ncc-Version in package-lock.json, erzeugt das CommonJS-Bundle dist/server.cjs und enthält sowohl keyring.darwin-arm64.node als auch keyring.darwin-x64.node. CommonJS ist beabsichtigt, da der native Keychain-Loader auf Node's __filename/createRequire-Verhalten angewiesen ist. Der Kaltinstallationscheck testet sowohl einen abhängigkeitsfreien Git-Snapshot als auch ein installiertes npm-Tarball.

Die Paketmetadaten sind strukturell bereit für ein zukünftiges öffentliches npm-Paket namens codex-multi-email, aber diese README behauptet nicht, dass der Name reserviert ist oder dass ein Paket veröffentlicht wurde. Ein Maintainer muss sich authentifizieren, den Besitz verifizieren, npm publish --dry-run überprüfen und explizit veröffentlichen.

Siehe CONTRIBUTING.md, SECURITY.md und CHANGELOG.md.

Fehlerbehebung

• Unbekannter Alias: führen Sie node ./scripts/multi-email list aus und verwenden Sie dann bei jedem Aufruf den exakten Alias.

• Verbindungsstatus unklar: rufen Sie mail_diagnose_accounts für einen Alias oder alle Aliase auf; es prüft das Vorhandensein von Anmeldedaten, die Token-Verwendbarkeit, Scopes und die Identität, ohne Nachrichten zu lesen oder Schreibvorgänge durchzuführen.

• Nicht autorisiert oder Token abgelaufen: führen Sie node ./scripts/multi-email auth <alias> erneut aus; fügen Sie niemals ein Token in den Chat ein.

• Review-Anfrage abgelaufen/abgelehnt: bereiten Sie eine neue Review vor und treffen Sie eine neue Entscheidung im lokalen Fenster.

• Entwurf nach Genehmigung geändert: überprüfen Sie den vollständigen neuen Entwurf erneut.

• Entwurf nicht überprüfbar: entfernen Sie HTML, Inline-Inhalte, Anhänge, alternative Absenderidentitäten oder zusätzliche Reply-To-Werte, oder erstellen Sie ihn als Klartext-Entwurf über Multi Email neu. Umgehen Sie das Gate nicht.

• Sendeergebnis ungewiss: nicht erneut versuchen; prüfen Sie zuerst Entwürfe und Gesendet im Nur-Lese-Modus.

• Gmail-Autorisierung blockiert: überprüfen Sie den OAuth-Zustimmungsbildschirm, den Testbenutzerstatus, den angeforderten Gmail-Bereich, die Konto-/Organisationsrichtlinie und den App-Verifizierungsstatus.

• Microsoft-Zustimmung blockiert: überprüfen Sie die Public-Client-Einstellungen, die Mandantenauswahl, delegierte Berechtigungen und die Administratorrichtlinie.

• Gemeinsames Postfach oder alternative From-Adresse: nicht unterstützt, bis die exakte delegierte Identität und die Berechtigungen implementiert und Ende-zu-Ende verifiziert sind.

Lizenz

MIT © 2026 Vincent_Lan. Siehe LICENSE.