Codex Cloud delegated tasks do not expose connected app/connector tools (e.g. Google Drive)

What issue are you seeing?

Connected app / connector capabilities that are configured for a project are not available after the task runs in Codex Cloud.

I encountered this specifically with Google Drive. The project already has a Google Drive folder mapping configured, but the cloud agent session has no usable Drive connector surface:

• no Google Drive MCP resource/template or callable Drive tool is exposed to the session;
• no Drive CLI fallback such as rclone, gdrive, or drive is available in the cloud environment;
• as a result, the agent cannot verify or perform an actual Drive download/upload.

This failure occurs before any Google Drive API request is attempted, so it does not appear to be an OAuth scope, file permission, or Drive API error. The cloud session simply has no path to the configured connector.

Steps to reproduce

1. Connect and authorize Google Drive as a ChatGPT/Codex connected app/plugin.
2. Configure a project/workflow that references or maps a Google Drive folder.
3. Delegate/run the coding task in Codex Cloud.
4. Ask the cloud agent to read, download, search, or upload a file in that configured Drive location.
5. Observe that the session does not expose a Drive MCP resource/template or callable Drive tool.
6. Check for common CLI fallbacks such as rclone, gdrive, or drive; none are available.
7. The agent therefore cannot validate or execute the Drive operation.

Expected behavior

If a connector is configured and supported by Codex, a delegated Codex Cloud task should either:

• expose the authorized connector tools/resources to the agent/tool layer, without exposing OAuth credentials to the shell/container; or
• clearly state before the cloud task starts that connected apps/connectors or project Drive mappings are not supported in Codex Cloud.

The preferred model would be:

Codex Cloud agent
├── cloud container / shell
├── repository tools
└── authorized connector tools
    └── Google Drive

The OAuth credential should remain isolated from shell commands and user code; the connector itself can remain a separately mediated tool capability.

Actual behavior

The cloud coding environment and repository are available, and the project retains the Drive-related configuration, but the corresponding connector capability is absent from the active cloud session.

There is also no container-side fallback CLI for Drive access. Therefore a workflow such as:

Read the PRD/spec from the configured Google Drive folder, then implement it in this repository using a Codex Cloud task.

cannot complete without manually copying/materializing the Drive content into the coding context before running the cloud task.

Why this is confusing

Codex presents connected apps/plugins such as Google Drive as Codex capabilities, and project configuration can retain Drive-related mappings, but the capability boundary for Codex Cloud delegated tasks is not obvious.

It is unclear whether this behavior is:

1. a bug where configured connector capabilities are not injected into the cloud task's tool manifest,
2. a rollout/configuration limitation,
3. an intentional security/runtime boundary, or
4. an unsupported Codex Cloud capability that needs explicit documentation and UI messaging.

Any of these would be useful to clarify. The current state is particularly confusing because the configuration exists while the execution surface required to use it does not.

Related issue

• #25854 — Google Drive connector connected but mcp__codex_apps__google_drive tools are not exposed in Codex Desktop.

That report is similar at the tool-injection layer, but this report is specifically about the Codex Cloud / delegated-task surface, including the case where project Drive configuration exists but the cloud session exposes neither the connector nor a CLI fallback.

Additional information

A concrete cloud-agent summary from the failed run was effectively:

Google Drive configuration exists, but the current session cannot invoke the connector. The project has a Drive folder mapping configured, but this agent session exposes no Drive MCP resource/template and has no rclone, gdrive, or drive CLI, so actual download/upload cannot be verified.

I can provide a specific cloud-task transcript / diagnostic information if maintainers indicate which identifiers or logs are useful.

If connectors are intentionally unsupported in delegated Codex Cloud tasks, please document that explicitly and surface the limitation at delegation/task-start time.