I’ve started experimenting with automations but I have found it to be unusable. I am running a total of 12 automations that are on relatively small repos one is around 10K lines of code, and the other is barely 1K.
These automations constantly find themselves reconnecting, or stalling. The most obvious error is this which I’ve seen has been open for a while on GitHub issues. stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses)
For me, the purpose of these coding agents / AI automations are so that I don’t have to sit and watch over them but instead they autonomously work on their own given prompt instructions but it’s at the point where I am considering alternatives over Codex. I am on a ChatGPT Pro subscription.
Each agent opens up its new chat session per automation.
I’m going to try a single agent worker model and see if that reduces these types of errors. My initial assumption is concurrency so we’ll try reducing that and I’ll report back to see what happens.
I think your instinct to test a single worker is the right move.
If each automation is opening its own chat session, then 12 automations may be creating a lot of fragile live state at once. Even if the repos are small, the issue may not be repo size. It may be session stability, concurrency, and what happens when a stream drops before the task has a durable checkpoint.
For unattended work, I have found it helps to treat the agent less like a chat window and more like a managed job.
One worker takes one task, records what it is doing outside the chat, saves progress after meaningful steps, and can resume from the last good point if the connection drops or the session stalls.
Then, once that is stable, add concurrency carefully.
The disconnects may still be on the platform side, but a single worker model should help you separate “Codex cannot do the task” from “too many live agent sessions are making the workflow unstable.”
Update: reducing the number of automations in parallel seems to have reduced the amount of errors. I still think there should be better support for higher amounts of concurrency but at least for now the issue is resolved.