Summary
The Microsoft 365 connectors are unsafe and not fit for purpose for multi-account or migration workflows unless Codex can explicitly select the Microsoft account, tenant, and mailbox context being used.
In a real migration workflow, the user may be signed into multiple Microsoft accounts. The connector can bind to an unexpected primary identity, while the user intends to inventory or migrate data from a different tenant/account. That makes even read-only inventory unsafe: the tool can access or attempt to access the wrong tenant before the user has a chance to correct it.
Why this matters
Migration and admin workflows often require moving data from one Microsoft 365 account/tenant to another. Multi-account operation is not an edge case; it is the core workflow. If Codex silently chooses the wrong Microsoft identity, the connector becomes unusable for professional M365 migration work.
Required behavior
- Show the active Microsoft account and tenant before any Outlook, Calendar, Teams, or SharePoint connector call.
- Allow explicit account/tenant selection per Microsoft connector connection.
- Support multiple named Microsoft connections, e.g. "Outlook - Source Tenant" and "Outlook - Destination Tenant".
- Let tool calls target a specific named connection/account.
- Fail closed if the requested account/tenant does not match the active connector identity.
- Never silently fall back to another signed-in Microsoft account.
- Expose delegated/shared mailbox context separately from the authenticated primary identity.
Expected result
Codex should make it impossible to accidentally inventory, read, or mutate the wrong Microsoft 365 tenant. Account and tenant identity need to be explicit, visible, and enforceable at the connector/tool-call layer.
Actual result
The connector can resolve to a Microsoft identity other than the one intended for the migration. The user cannot reliably force the connector to use the intended signed-in account from within Codex, making the workflow unsafe.
Severity
High for M365 migration, admin, and multi-tenant consulting workflows. This is both a usability blocker and a data-boundary safety issue.
Summary
The Microsoft 365 connectors are unsafe and not fit for purpose for multi-account or migration workflows unless Codex can explicitly select the Microsoft account, tenant, and mailbox context being used.
In a real migration workflow, the user may be signed into multiple Microsoft accounts. The connector can bind to an unexpected primary identity, while the user intends to inventory or migrate data from a different tenant/account. That makes even read-only inventory unsafe: the tool can access or attempt to access the wrong tenant before the user has a chance to correct it.
Why this matters
Migration and admin workflows often require moving data from one Microsoft 365 account/tenant to another. Multi-account operation is not an edge case; it is the core workflow. If Codex silently chooses the wrong Microsoft identity, the connector becomes unusable for professional M365 migration work.
Required behavior
Expected result
Codex should make it impossible to accidentally inventory, read, or mutate the wrong Microsoft 365 tenant. Account and tenant identity need to be explicit, visible, and enforceable at the connector/tool-call layer.
Actual result
The connector can resolve to a Microsoft identity other than the one intended for the migration. The user cannot reliably force the connector to use the intended signed-in account from within Codex, making the workflow unsafe.
Severity
High for M365 migration, admin, and multi-tenant consulting workflows. This is both a usability blocker and a data-boundary safety issue.