Multi Email

Multi Email es un plugin de Codex de código abierto y un servidor MCP para buzones de Gmail y Microsoft 365 con autorización independiente. Cada operación nombra un account_alias explícito; no hay buzón activo implícito.

Admite búsqueda, lectura, redacción de borradores, archivado, cambios de estado de leído/no leído, etiquetas de Gmail, categorías de Microsoft y envío a través de una ventana de revisión localhost impuesta por el servidor.

Estado de la versión: 0.1.2 es oficial solo cuando se instala desde la etiqueta anotada v0.1.2 o la versión correspondiente de GitHub en lanfuli/multi-email. El paquete npm codex-multi-email aún no está publicado; verifica el propietario del repositorio y la etiqueta de versión antes de la instalación.

Por qué existe esto

La mayoría de las integraciones de correo electrónico asumen una cuenta activa. Multi Email mantiene el enrutamiento explícito para que una solicitud pueda cubrir varias cuentas con autorización independiente sin mezclar IDs de mensajes, borradores, etiquetas o credenciales.

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

El proceso MCP y el almacén de credenciales se ejecutan en el Mac, pero el flujo de trabajo de extremo a extremo no es necesariamente solo local. Las indicaciones y los resultados de las herramientas, incluido el contenido de correo seleccionado, pueden ser procesados por Codex/OpenAI según la configuración de producto, cuenta y control de datos del usuario. Google y Microsoft también procesan el tráfico de la API del proveedor. Consulta Seguridad, privacidad y flujo de datos.

Related MCP server: Gmail MCP Server

Modelo de seguridad

• Cada operación requiere un account_alias explícito.

• Las lecturas son el valor predeterminado de la habilidad; las mutaciones requieren una solicitud de usuario actual y explícita.

• La eliminación permanente no está expuesta.

• Los cuerpos de correo, archivos adjuntos, texto citado, firmas y enlaces se tratan como datos no confiables, nunca como instrucciones de herramientas.

• El tamaño de búsqueda, lote de escritura, destinatarios y cuerpo están limitados.

• El envío está bloqueado hasta que el usuario revise el borrador completo de texto plano admitido en una ventana 127.0.0.1 y haga clic en Aprobar.

• Un approval_request_id de corta duración está vinculado a un manifiesto de envío efectivo: principal autenticado, buzón, identidad de remitente efectiva, identidad de borrador e hilo, cada destinatario, asunto, cuerpo completo, revisión del proveedor y la ausencia verificada de archivos adjuntos. La aprobación caduca, es de un solo uso y se invalida ante cualquier cambio vinculado.

• La versión 0.1.2 falla de forma segura antes de la revisión o el envío cuando un borrador del proveedor contiene HTML, MIME multiparte o desconocido, contenido en línea, archivos adjuntos, una dirección de buzón mal formada, una identidad From/Sender/Reply-To no admitida o una revisión del proveedor incompleta.

• La solicitud de envío al proveedor se construye a partir de los campos de texto plano permitidos y aprobados. Gmail suministra ese mensaje crudo congelado en la solicitud de envío de borrador; Microsoft usa una solicitud MIME sendMail en lugar de enviar un borrador mutable del proveedor.

• Ninguna herramienta MCP puede aprobar su propia solicitud de envío.

• Un envío nunca se reintenta automáticamente después de un resultado ambiguo porque el proveedor ya puede haberlo aceptado.

Estos controles reducen acciones accidentales e inducidas por indicaciones; no hacen que los tokens OAuth sean de solo lectura. Los permisos gmail.modify de Google y Mail.ReadWrite más Mail.Send de Microsoft otorgan acceso material al buzón.

Operaciones admitidas

El plugin no llama intencionalmente a los endpoints de contenido de archivos adjuntos del proveedor, no expone contenidos de archivos adjuntos a través de MCP, no elimina correo permanentemente, no opera calendarios, no expone APIs arbitrarias del proveedor, ni habilita automáticamente alias de envío, identidades delegadas o buzones compartidos. Las respuestas de Gmail con format=full aún pueden entregar pequeños bytes de partes MIME en línea al proceso local; no son devueltos por la herramienta. Las lecturas de mensajes exponen solo nombres de archivos adjuntos. Los borradores creados por el plugin son texto plano. Los borradores del proveedor que contienen HTML, contenido en línea, archivos adjuntos, direcciones de buzón mal formadas o identidades no admitidas no pueden pasar la puerta de revisión de envío en la versión 0.1.2.

Las consultas de búsqueda son nativas del proveedor: sintaxis de búsqueda de Gmail para Google y sintaxis de búsqueda de correo de Microsoft Graph para Microsoft 365.

mail_list_accounts informa si existe una credencial local con credentialPresent y connectionStatus (credential_present_unverified o not_authorized). Esos campos no son afirmaciones de autenticación. Usa mail_diagnose_accounts para verificar la salud actual del token, alcance e identidad del proveedor.

Requisitos

• macOS en Apple Silicon o Intel

• Node.js 22 o más reciente

• Codex de escritorio o CLI con soporte de MCP stdio local y plugin

• Un cliente OAuth de escritorio de Google Cloud con la API de Gmail habilitada para cuentas de Gmail

• Una aplicación pública de Microsoft Entra para cuentas de Microsoft 365

El paquete dist/ incluido contiene sus dependencias de JavaScript y ambos binarios nativos de Keychain de macOS, por lo que una instantánea de marketplace de Git puede iniciarse sin un directorio node_modules/ incluido. El desarrollo y las importaciones de bibliotecas npm aún usan dependencias npm normales.

Instalar desde GitHub

La instalación más transparente es un clon local:

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

Inicia una nueva tarea de Codex después de la instalación para que se descubran la habilidad y las herramientas MCP.

Codex también acepta una fuente de marketplace de Git una vez que el repositorio existe:

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

El --ref explícito mantiene la instantánea instalada en la versión revisada en lugar de la rama predeterminada en movimiento. La entrada de marketplace del repositorio usa la fuente local documentada en la raíz del repositorio ("./"). El esquema actual documentado de marketplace de Codex también tiene formas de fuente URL, git-subdir y npm; este repositorio no usa una fuente npm porque no se ha realizado ninguna publicación npm.

Los ejemplos de configuración a continuación se ejecutan desde el clon local correspondiente. Una futura instalación npm puede usar el binario equivalente multi-email ... directamente; no ejecutes npm run setup desde un proyecto consumidor.

Configurar OAuth

La ruta de configuración predeterminada es:

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

Establece CODEX_MULTI_EMAIL_CONFIG para usar otra ruta absoluta. El CLI de configuración crea un directorio de configuración faltante con modo 0700, deja sin cambios los permisos de un directorio padre existente, escribe el archivo de configuración con modo 0600 y rechaza un destino de configuración que sea un enlace simbólico o un archivo no regular.

Inicializa cualquiera de los proveedores de forma independiente, o proporciona ambos ajustes de proveedor en un solo comando.

Solo Google:

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

Solo Microsoft:

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

Ambos proveedores:

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

Para agregar o reemplazar ajustes de Microsoft más tarde:

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

Agrega y autoriza cada buzón de forma independiente:

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

Usa marcadores de posición solo en la documentación; no confirmes direcciones reales, JSON de cliente OAuth, configuración generada, URLs de autorización, códigos o tokens.

OAuth de Google

La autorización de Google solicita openid, email y gmail.modify a través de un flujo OAuth de escritorio de bucle local. El perfil de Gmail devuelto debe coincidir exactamente con la dirección configurada antes de que los tokens se almacenen en Keychain.

Las credenciales OAuth propias no eximen a una aplicación o usuario de los requisitos de verificación, pantalla de consentimiento, usuarios de prueba, alcances restringidos, organización, cuota o retención de Google. Un proyecto OAuth dejado en Testing puede comportarse de manera diferente a una aplicación de producción verificada, y las cuentas individuales o los administradores aún pueden bloquear el acceso.

OAuth de Microsoft

La autorización de Microsoft usa autorización interactiva del navegador del sistema MSAL y solicita User.Read, Mail.ReadWrite y Mail.Send delegados. El perfil /me debe coincidir con la identidad configurada antes de que se almacene la caché de MSAL. La política del inquilino o el consentimiento del administrador pueden bloquear estos alcances.

Uso en Codex

Siempre nombra el alias de cuenta:

• "Usa gmail-01 para encontrar mensajes no leídos de los últimos dos días."

• "En gmail-01 y m365-main, resume los mensajes que necesitan mi respuesta sin hacer cambios."

• "Crea un borrador de respuesta en m365-main; no lo envíes."

• "Diagnostica todas las cuentas configuradas sin leer ni cambiar el correo."

Para un envío:

1. Pide a Codex que prepare el borrador seleccionado para revisión.

2. Inspecciona la identidad autenticada, el From/Sender/Reply-To efectivo, cada destinatario, asunto, encabezados de hilo, formato, estado de archivos adjuntos y el cuerpo completo de texto plano en la ventana de localhost abierta por el servidor MCP.

3. Haz clic en Aprobar o Rechazar en esa ventana.

4. Vuelve a Codex y confirma explícitamente que la revisión local está completa.

5. El servidor reconstruye el manifiesto de envío efectivo, gasta la aprobación de un solo uso, vuelve a verificar la revisión del proveedor y congela los campos permitidos aprobados en una solicitud de envío.

6. Un envío congelado de Microsoft conserva intencionalmente el borrador fuente original porque la acción de envío de borrador existente de Graph no tiene guardia de revisión condicional. Verifica el campo de resultado sourceDraftRetained; no envíes ese borrador retenido nuevamente sin una nueva revisión.

No pegues la URL de revisión local, cookies, nonces, huellas digitales, valores OAuth o contenidos de Keychain en Codex o en un issue.

Actualizar

Para un marketplace de clon local:

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

Reemplaza v0.1.2 solo con una etiqueta de versión anotada más reciente que hayas revisado. Un marketplace de Git instalado con --ref permanece fijado, así que muévelo a una nueva versión explícitamente:

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

Inicia una nueva tarea de Codex después de reinstalar.

Desinstalar y eliminar datos locales

Elimina el plugin y el marketplace:

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

La eliminación del plugin no borra credenciales OAuth ni configuración. Prefiere los comandos de ciclo de vida protegidos antes de eliminar el clon:

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

logout elimina las credenciales locales. revoke también intenta la revocación del lado del proveedor cuando el proveedor lo admite de manera segura; Microsoft puede requerir la eliminación a través de Microsoft My Apps seguida de logout. Inspecciona el resultado del comando en lugar de asumir que la revocación del proveedor tuvo éxito.

Los elementos actuales de Keychain usan el servicio io.github.lanfuli.multi-email. Las instalaciones históricas también pueden tener elementos heredados verificados bajo com.openai.codex.multi-email; el almacén de credenciales migra solo después de validar la identidad del proveedor, mientras que doctor es deliberadamente de solo lectura y nunca migra. Usa Acceso a Llaveros de macOS para la limpieza heredada opcional e inspecciona la ruta de configuración exacta antes de eliminar ~/.config/codex-multi-email/config.json.

Desarrollo

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

npm run build usa la versión exacta de @vercel/ncc en package-lock.json, emite el paquete CommonJS dist/server.cjs e incluye tanto keyring.darwin-arm64.node como keyring.darwin-x64.node. CommonJS es intencional porque el cargador nativo de Keychain depende del comportamiento de __filename/createRequire de Node. La verificación de instalación en frío prueba tanto una instantánea de Git sin dependencias como un tarball npm instalado.

Los metadatos del paquete están estructuralmente listos para un futuro paquete npm público llamado codex-multi-email, pero este README no afirma que el nombre esté reservado o que un paquete esté publicado. Un mantenedor debe autenticarse, verificar la propiedad, inspeccionar npm publish --dry-run y publicar explícitamente.

Consulta CONTRIBUTING.md, SECURITY.md y CHANGELOG.md.

Solución de problemas

• Alias desconocido: ejecuta node ./scripts/multi-email list y usa el alias exacto en cada llamada.

• Estado de la conexión poco claro: llama a mail_diagnose_accounts para un alias o para todos; comprueba la presencia de credenciales, la usabilidad del token, los ámbitos y la identidad sin leer mensajes ni realizar escrituras.

• No autorizado o token caducado: vuelve a ejecutar node ./scripts/multi-email auth <alias>; nunca pegues un token en el chat.

• Solicitud de revisión caducada/rechazada: prepara una nueva revisión y toma una nueva decisión en la ventana local.

• Borrador modificado tras la aprobación: revisa de nuevo el borrador completo.

• Borrador no revisable: elimina HTML, contenido en línea, archivos adjuntos, identidades de remitente alternativas o valores adicionales de Reply-To, o recréalo como borrador de texto plano mediante Multi Email. No omitas la compuerta.

• Resultado del envío incierto: no reintentes; inspecciona primero Borradores y Enviados en modo de solo lectura.

• Autorización de Gmail bloqueada: verifica la pantalla de consentimiento de OAuth, el estado de usuario de prueba, el ámbito de Gmail solicitado, la política de la cuenta/organización y el estado de verificación de la aplicación.

• Consentimiento de Microsoft bloqueado: verifica la configuración de cliente público, la elección de inquilino, los permisos delegados y la política del administrador.

• Buzón compartido o dirección From alternativa: no compatible hasta que se implementen y verifiquen de extremo a extremo la identidad delegada exacta y los permisos.

Licencia

MIT © 2026 Vincent_Lan. Consulta LICENSE.