Outlook connector (workspace agents): folder discovery capped at ~500 folders — deep/wide subfolders are invisible, search by exact name/path returns empty

ChatGPT Bugs
1

Looking for a setting I’ve missed before building a custom connector — which feels heavy for a basic “find a folder” capability.

Setup

A ChatGPT Business/Enterprise workspace agent using the native Outlook connector to file mail into subfolders. One mailbox was migrated, so mail lives under Imported/Inbox/<client> — and that Inbox has ~890 direct child folders (~4,500 folders total).

Symptom

The agent can’t find target subfolders, reports they “don’t exist / may be local PST,” can’t get a folder id, can’t move mail.

I verified via Microsoft Graph (same tenant app, read-only) that every folder is fully server-side: valid id, isHidden:false, reachable via childFolders (from inbox and msgfolderroot) and /mailFolders/delta. Not PST, not permissions, not hidden — discovery layer only.

Reproducible test

Test mailbox: one folder with 889 children (f0001…f0889); two probes, each with a leaf subfolder:

  • NEAR at position 12 → LEAF-NEAR
  • FAR at position 780 → LEAF-FAR

Connector folder tools:

  • Find folders by name/path → query, include_hidden_folders, max_results
  • List folders (flat) → include_hidden_folders, top (bounded 1–500)
  • Move email → destination_folder_id | destination_well_known_folder, message_id

No “list children of a parent id”. No pagination input (next_link is in the response but always null, with no way to pass one back).

Observed:

  1. Flat list (top=500) returns alphabetically, stops at f0487, next_link:null — a single enumeration capped at ~500 total folders.
  2. Find by name (max_results=5000) for f0780-... → {"results":[]}. Search is not a live Graph query; it filters the truncated ~500 set. Exact-name/path lookup past the cap returns empty.
  3. NEAR (pos 12) found, but its leaf LEAF-NEAR is not — enumeration is breadth-first and burns the 500 budget on the wide level before descending one level.
  4. FAR (pos 780) not found at all.
  5. Move with an explicit destination_folder_id works — moved a message into the pos-780 folder (which search can’t find) by id, then back. Only discovery is broken.

Why I’m asking instead of building a connector

Everything I need exists except resolving a folder id in a large mailbox. Graph does this trivially (childFolders + $top=999 + @odata.nextLink, $expand=childFolders, or /delta). A full custom MCP just to look up a folder id seems disproportionate.

Questions

  1. Any way to raise the ~500 cap or paginate the flat list (honor next_link / accept skip/cursor)?
  2. Is a server-side folder search (name/path via Graph) available or planned?
  3. Any way to list child folders of a specific parent id through the connector?
  4. If not today — recommended approach for mailboxes with >500 folders (or one folder with >500 children) that avoids a full custom connector?

Happy to share the full repro (counts, positions, literal tool JSON) for triage. Thanks!