Multi Email

Multi Email은 독립적으로 인증된 Gmail 및 Microsoft 365 사서함을 위한 오픈소스 Codex 플러그인 및 MCP 서버입니다. 모든 작업은 명시적인 account_alias를 지정하며, 암시적 활성 사서함은 없습니다.

검색, 읽기, 초안 작성, 보관, 읽음 상태 변경, Gmail 라벨, Microsoft 카테고리, 그리고 서버가 강제하는 localhost 검토 창을 통한 전송을 지원합니다.

릴리스 상태: 0.1.2는 lanfuli/multi-email의 주석이 달린 v0.1.2 태그 또는 일치하는 GitHub 릴리스에서 설치한 경우에만 공식 버전입니다. codex-multi-email npm 패키지는 아직 게시되지 않았습니다. 설치 전에 저장소 소유자와 릴리스 태그를 확인하세요.

존재 이유

대부분의 이메일 통합은 하나의 활성 계정을 가정합니다. Multi Email은 라우팅을 명시적으로 유지하여 하나의 요청이 여러 독립적으로 인증된 계정을 다룰 수 있게 하며, 메시지 ID, 초안, 라벨 또는 자격 증명이 섞이지 않도록 합니다.

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

MCP 프로세스와 자격 증명 저장소는 Mac에서 실행되지만, 종단 간 워크플로가 반드시 로컬 전용인 것은 아닙니다. 선택한 메일 콘텐츠를 포함한 프롬프트와 도구 결과는 사용자의 제품, 계정 및 데이터 제어 설정에 따라 Codex/OpenAI에서 처리될 수 있습니다. Google과 Microsoft도 제공업체 API 트래픽을 처리합니다. 보안, 개인정보 및 데이터 흐름을 참조하세요.

Related MCP server: Gmail MCP Server

안전 모델

• 모든 작업에는 명시적인 account_alias가 필요합니다.

• 읽기는 스킬의 기본 동작입니다. 변경 작업에는 현재의 명시적인 사용자 요청이 필요합니다.

• 영구 삭제는 노출되지 않습니다.

• 이메일 본문, 첨부 파일, 인용 텍스트, 서명 및 링크는 신뢰할 수 없는 데이터로 취급되며 도구 지침으로 간주되지 않습니다.

• 검색, 쓰기 배치, 수신자 및 본문 크기는 제한됩니다.

• 사용자가 127.0.0.1 창에서 지원되는 전체 일반 텍스트 초안을 검토하고 승인을 클릭할 때까지 전송이 차단됩니다.

• 수명이 짧은 approval_request_id는 유효 전송 매니페스트에 바인딩됩니다: 인증된 주체, 사서함, 유효 발신자 ID, 초안 및 스레드 ID, 모든 수신자, 제목, 전체 본문, 제공업체 개정 버전, 그리고 첨부 파일이 없음이 검증된 상태. 승인은 만료되며, 일회용이고, 바인딩된 변경 사항이 있으면 무효화됩니다.

• 버전 0.1.2는 제공업체 초안에 HTML, multipart 또는 알 수 없는 MIME, 인라인 콘텐츠, 첨부 파일, 잘못된 형식의 사서함 주소, 지원되지 않는 From/Sender/Reply-To ID, 또는 불완전한 제공업체 개정 버전이 포함된 경우 검토 또는 전송 전에 안전하게 차단합니다.

• 제공업체 전송 요청은 승인된 허용 목록(allowlisted) 일반 텍스트 필드로 구성됩니다. Gmail은 동결된 원시 메시지를 초안 전송 요청에 제공합니다. Microsoft는 변경 가능한 제공업체 초안을 보내는 대신 하나의 MIME sendMail 요청을 사용합니다.

• 어떤 MCP 도구도 자신의 전송 요청을 승인할 수 없습니다.

• 모호한 결과 후 전송이 자동으로 재시도되지 않습니다. 제공업체가 이미 수락했을 수 있기 때문입니다.

이러한 제어는 우발적 및 프롬프트 주입 작업을 줄여줍니다. OAuth 토큰을 읽기 전용으로 만들지는 않습니다. Google gmail.modify와 Microsoft Mail.ReadWrite 및 Mail.Send는 실질적인 사서함 액세스 권한을 부여합니다.

지원되는 작업

플러그인은 의도적으로 제공업체 첨부 콘텐츠 엔드포인트를 호출하지 않으며, MCP를 통해 첨부 콘텐츠를 노출하지 않고, 메일을 영구 삭제하지 않으며, 캘린더를 운영하지 않고, 임의의 제공업체 API를 노출하지 않으며, send-as 별칭, 위임된 ID 또는 공유 사서함을 자동으로 활성화하지 않습니다. Gmail format=full 응답은 여전히 작은 인라인 MIME 파트 바이트를 로컬 프로세스에 전달할 수 있습니다. 도구로 반환되지는 않습니다. 메시지 읽기는 첨부 파일 이름만 노출합니다. 플러그인이 만든 초안은 일반 텍스트입니다. HTML, 인라인 콘텐츠, 첨부 파일, 잘못된 형식의 사서함 주소 또는 지원되지 않는 ID가 포함된 제공업체 초안은 버전 0.1.2의 전송 검토 게이트를 통과할 수 없습니다.

검색 쿼리는 제공업체 기본 방식입니다. Google은 Gmail 검색 구문, Microsoft 365는 Microsoft Graph 메일 검색 구문을 사용합니다.

mail_list_accounts는 credentialPresent 및 connectionStatus(credential_present_unverified 또는 not_authorized)로 로컬 자격 증명이 존재하는지 보고합니다. 이러한 필드는 인증 주장이 아닙니다. 현재 토큰, 범위 및 제공업체 ID 상태를 확인하려면 mail_diagnose_accounts를 사용하세요.

요구 사항

• Apple Silicon 또는 Intel의 macOS

• Node.js 22 이상

• 로컬 stdio MCP 및 플러그인을 지원하는 Codex 데스크톱 또는 CLI

• Gmail 계정용 Gmail API가 활성화된 Google Cloud Desktop OAuth 클라이언트

• Microsoft 365 계정용 Microsoft Entra 공용 클라이언트 애플리케이션

커밋된 dist/ 번들에는 JavaScript 종속성과 두 macOS Keychain 네이티브 바이너리가 포함되어 있으므로 Git 마켓플레이스 스냅샷은 커밋된 node_modules/ 디렉터리 없이 시작할 수 있습니다. 개발 및 npm 라이브러리 가져오기는 여전히 일반 npm 종속성을 사용합니다.

GitHub에서 설치

가장 투명한 설치는 로컬 클론입니다:

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

설치 후 스킬과 MCP 도구가 발견되도록 새 Codex 작업을 시작하세요.

저장소가 존재하면 Codex는 Git 마켓플레이스 소스도 허용합니다:

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

명시적인 --ref는 이동하는 기본 브랜치 대신 검토된 릴리스에 설치된 스냅샷을 유지합니다. 저장소 마켓플레이스 항목은 문서화된 저장소 루트 로컬 소스("./")를 사용합니다. 현재 문서화된 Codex 마켓플레이스 스키마에는 URL, git-subdir 및 npm 소스 형식도 있습니다. 이 저장소는 npm 게시가 없었으므로 npm 소스를 사용하지 않습니다.

아래의 설정 예제는 일치하는 로컬 클론에서 실행됩니다. 향후 npm 설치는 동등한 multi-email ... 바이너리를 직접 사용할 수 있습니다. 사용 프로젝트에서 npm run setup을 실행하지 마세요.

OAuth 구성

기본 구성 경로는 다음과 같습니다:

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

다른 절대 경로를 사용하려면 CODEX_MULTI_EMAIL_CONFIG를 설정하세요. 설정 CLI는 누락된 구성 디렉터리를 모드 0700으로 생성하고, 기존 상위 디렉터리의 권한은 변경하지 않으며, 구성 파일을 모드 0600으로 작성하고, 심볼릭 링크 또는 일반 파일이 아닌 구성 대상을 거부합니다.

각 제공업체를 독립적으로 초기화하거나 한 명령에서 두 제공업체 설정을 모두 제공하세요.

Google만:

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

Microsoft만:

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

두 제공업체 모두:

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

나중에 Microsoft 설정을 추가하거나 교체하려면:

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

각 사서함을 독립적으로 추가하고 인증하세요:

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

문서에는 자리 표시자만 사용하세요. 실제 주소, OAuth 클라이언트 JSON, 생성된 구성, 인증 URL, 코드 또는 토큰을 커밋하지 마세요.

Google OAuth

Google 인증은 루프백 Desktop OAuth 흐름을 통해 openid, email 및 gmail.modify를 요청합니다. 반환된 Gmail 프로필은 토큰이 Keychain에 저장되기 전에 구성된 주소와 정확히 일치해야 합니다.

자체 OAuth 자격 증명을 사용한다고 해서 앱이나 사용자가 Google의 검증, 동의 화면, 테스트 사용자, 제한된 범위, 조직, 할당량 또는 보존 요구 사항에서 면제되지는 않습니다. Testing 상태로 남겨진 OAuth 프로젝트는 검증된 프로덕션 앱과 다르게 동작할 수 있으며, 개별 계정이나 관리자가 여전히 액세스를 차단할 수 있습니다.

Microsoft OAuth

Microsoft 인증은 MSAL 시스템 브라우저 대화형 인증을 사용하며 위임된 User.Read, Mail.ReadWrite 및 Mail.Send를 요청합니다. MSAL 캐시가 저장되기 전에 /me 프로필이 구성된 ID와 일치해야 합니다. 테넌트 정책 또는 관리자 동의가 이러한 범위를 차단할 수 있습니다.

Codex에서 사용

항상 계정 별칭을 지정하세요:

• "gmail-01을 사용하여 지난 이틀 동안의 읽지 않은 메시지를 찾아줘."

• "gmail-01과 m365-main에서 변경 없이 내 답변이 필요한 메시지를 요약해줘."

• "m365-main에 답장 초안을 만들어줘. 보내지 마."

• "메일을 읽거나 변경하지 않고 구성된 모든 계정을 진단해줘."

전송의 경우:

1. Codex에 선택한 초안을 검토용으로 준비하도록 요청하세요.

2. MCP 서버가 연 localhost 창에서 인증된 ID, 유효 From/Sender/Reply-To, 모든 수신자, 제목, 스레딩 헤더, 형식, 첨부 상태 및 전체 일반 텍스트 본문을 검사하세요.

3. 해당 창에서 승인 또는 거부를 클릭하세요.

4. Codex로 돌아와 로컬 검토가 완료되었음을 명시적으로 확인하세요.

5. 서버가 유효 전송 매니페스트를 다시 구성하고, 일회용 승인을 사용하고, 제공업체 개정 버전을 다시 확인하고, 승인된 허용 목록 필드를 하나의 전송 요청으로 동결합니다.

6. Microsoft 동결 전송은 Graph의 기존 초안 전송 작업에 조건부 개정 가드가 없기 때문에 의도적으로 원본 소스 초안을 유지합니다. 결과 필드 sourceDraftRetained를 확인하세요. 새 검토 없이 유지된 초안을 다시 보내지 마세요.

로컬 검토 URL, 쿠키, nonce, 지문, OAuth 값 또는 Keychain 내용을 Codex나 이슈에 붙여넣지 마세요.

업데이트

로컬 클론 마켓플레이스의 경우:

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

v0.1.2는 검토한 최신 주석 릴리스 태그로만 교체하세요. --ref로 설치된 Git 마켓플레이스는 고정된 상태로 유지되므로 새 릴리스로 명시적으로 이동하세요:

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

재설치 후 새 Codex 작업을 시작하세요.

제거 및 로컬 데이터 삭제

플러그인과 마켓플레이스를 제거하세요:

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

플러그인 제거는 OAuth 자격 증명이나 구성을 삭제하지 않습니다. 클론을 삭제하기 전에 보호된 수명 주기 명령을 사용하는 것이 좋습니다:

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

logout은 로컬 자격 증명을 제거합니다. revoke는 제공업체가 안전하게 지원하는 경우 제공업체 측 폐기도 시도합니다. Microsoft는 Microsoft My Apps를 통한 제거 후 logout이 필요할 수 있습니다. 제공업체 폐기가 성공했다고 가정하지 말고 명령 결과를 확인하세요.

현재 Keychain 항목은 서비스 io.github.lanfuli.multi-email을 사용합니다. 이전 설치에는 com.openai.codex.multi-email 아래에 검증된 레거시 항목이 있을 수도 있습니다. 자격 증명 저장소는 제공업체 ID를 검증한 후에만 마이그레이션하며, doctor는 의도적으로 읽기 전용이며 마이그레이션하지 않습니다. 선택적 레거시 정리를 위해 macOS Keychain Access를 사용하고, ~/.config/codex-multi-email/config.json을 삭제하기 전에 정확한 구성 경로를 확인하세요.

개발

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

npm run build는 package-lock.json의 정확한 @vercel/ncc 버전을 사용하고, CommonJS 번들 dist/server.cjs를 생성하며, keyring.darwin-arm64.node와 keyring.darwin-x64.node를 모두 포함합니다. 네이티브 Keychain 로더가 Node의 __filename/createRequire 동작에 의존하므로 CommonJS는 의도적입니다. 콜드 설치 검사는 종속성이 없는 Git 스냅샷과 설치된 npm tarball을 모두 테스트합니다.

패키지 메타데이터는 codex-multi-email이라는 향후 공개 npm 패키지를 위해 구조적으로 준비되어 있지만, 이 README는 이름이 예약되었거나 패키지가 게시되었다고 주장하지 않습니다. 유지관리자는 인증하고, 소유권을 확인하고, npm publish --dry-run을 검사하고, 명시적으로 게시해야 합니다.

CONTRIBUTING.md, SECURITY.md, CHANGELOG.md를 참조하세요.

문제 해결

• 알 수 없는 별칭: node ./scripts/multi-email list를 실행한 후 모든 호출에서 정확한 별칭을 사용하세요.

• 연결 상태가 불명확한 경우: 하나의 별칭 또는 모든 별칭에 대해 mail_diagnose_accounts를 호출하세요. 메시지를 읽거나 쓰지 않고 자격 증명 존재 여부, 토큰 사용 가능성, 범위, ID를 확인합니다.

• 인증되지 않음 또는 토큰 만료: node ./scripts/multi-email auth <alias>를 다시 실행하세요. 토큰을 채팅에 붙여넣지 마세요.

• 검토 요청 만료/거부: 새 검토를 준비하고 로컬 창에서 새 결정을 내리세요.

• 승인 후 초안이 변경된 경우: 새 초안 전체를 다시 검토하세요.

• 검토할 수 없는 초안: HTML, 인라인 콘텐츠, 첨부 파일, 대체 보낸사람 ID, 추가 Reply-To 값을 제거하거나 Multi Email을 통해 일반 텍스트 초안으로 다시 만드세요. 게이트를 우회하지 마세요.

• 전송 결과가 불확실한 경우: 재시도하지 마세요. 먼저 Drafts와 Sent를 읽기 전용으로 검사하세요.

• Gmail 인증 차단됨: OAuth 동의 화면, 테스트 사용자 상태, 요청된 Gmail 범위, 계정/조직 정책, 앱 검증 상태를 확인하세요.

• Microsoft 동의 차단됨: 공용 클라이언트 설정, 테넌트 선택, 위임된 권한, 관리자 정책을 확인하세요.

• 공유 사서함 또는 대체 From 주소: 정확한 위임 ID와 권한이 구현되고 종단 간 검증될 때까지 지원되지 않습니다.

라이선스

MIT © 2026 Vincent_Lan. LICENSE를 참조하세요.