Automations fail to use MCP servers

Resolved 💬 2 comments Opened Mar 15, 2026 by virgildotcodes Closed Jun 22, 2026

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.311.21342 (993)

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 25.3.0 arm64 arm

What issue are you seeing?

I attempted to create an automation that would summarize Trello activity over the last 24h. I have a Trello MCP server configured that works just fine in normal sessions, but when I attempted to run the automation it completely failed to be able to use it, apparently due to sandbox restrictions.

What steps can reproduce the bug?

Set up Trello MCP server, create an automation using it, and try to run the automation.

What is the expected behavior?

MCP servers should be usable, automation permissions should likely be configurable.

Additional information

Feedback ID - 019cf10f-5235-7961-a784-a64a032b0906

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 5 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#14590
#14423
#14053

Powered by Codex Action

virgildotcodes · 5 months ago

Adding Codex assessment of the sequence of events:

The main problem was a combination of environment and integration details:

The configured trello MCP server in your Codex config uses bunx @delorenj/mcp-server-trello.
In that run, bunx was failing before the server could initialize because it couldn’t write to its temp/cache area. That is effectively an environment/permission issue, but not a Trello auth issue.
The Trello credentials themselves were present and valid.
I then tried to bypass the Codex MCP wrapper manually. That exposed two more issues:
npm also had a local cache permission problem until I redirected it to /tmp.
The Trello MCP package speaks newline-delimited JSON over stdio, not Content-Length framing, so my first manual client attempt used the wrong transport assumptions.
So the short version is: partly sandbox/tempdir permissions, but also partly the specific launcher setup (bunx) and partly protocol/tooling details when I fell back to driving the server manually.

If that earlier run had been in the current danger-full-access mode, the bunx startup problem likely would have gone away and the Trello MCP probably would have worked normally through Codex without the workaround.