why does composer install hang when an ai agent runs it

Composer is almost certainly blocked on an interactive prompt, for example a plugin allow-list question or a VCS authentication prompt, with no terminal to answer it. Atlas's bash tool races the command against a timeout so the hang surfaces, and the message explicitly calls out the interactive-input case.

how do i know if my php command is slow or stuck

Read Atlas's shell_metadata block. Atlas says to retry with a larger timeout only if the command is expected to take longer and is not waiting for interactive input. A blocked-on-stdin command never resolves by waiting, so if the last output was a question rather than progress, it is blocked.

what non-interactive flag stops composer from prompting

Composer takes a non-interaction flag that turns every question into its default answer. The general Atlas guidance is to re-run with the tool's non-interactive flags (-y, --no-input, CI mode) so it cannot prompt. Once the command cannot prompt, a second hang means it is genuinely slow.

how do i increase the bash timeout in atlas for a slow phpunit run

Retry with a larger timeout value in milliseconds, as Atlas's message instructs. A full PHPUnit suite against a real database legitimately runs past the default. Raise the timeout for that specific command rather than globally, so a genuinely stuck command still surfaces quickly everywhere else.

does atlas lose output from a long php command

No. When output exceeds the limits, Atlas's bash tool saves the full log to a file you can read with the read tool. So a long PHPUnit run or a verbose PHP-CS-Fixer pass across src/ leaves a complete record rather than a silently truncated one.

what does user aborted the command mean in atlas

It means you interrupted the process yourself, not that it timed out. Atlas's bash metadata distinguishes your interrupt from a timeout and from a non-zero exit code, which prevents the wasted effort of raising a timeout for a PHP command that was never actually timing out.

can atlas diagnose a hanging symfony console command

Yes. Run it through the bash tool, read the shell_metadata block when it is killed, and check whether the message points at interactive input. Framework console commands in bin/ prompt on confirmation questions, so the fix is usually a --no-input or CI mode flag rather than a longer timeout.

Diagnose a Hanging or Long-Running PHP Command With Atlas (2026)

To diagnose a hanging or long-running command in PHP with Atlas, run it through the bash tool and read the shell_metadata block when the command is killed. Atlas's bash tool races every command against a timeout and, when it expires, tells you exactly what happened and what to do: retry with a larger timeout if the command is expected to take longer and is not waiting for interactive input. That second clause is the diagnosis. A Composer command blocked on a stdin prompt never resolves by waiting, so the fix is Composer's non-interactive flag, not a bigger number. A genuinely slow PHPUnit suite is the opposite case, and there a larger timeout is exactly right.

Why does my Composer command hang forever inside an AI agent?

A hanging Composer command is almost always blocked on stdin, not slow. Atlas's bash tool races every command against a timeout and, when it expires, separates the 2 causes: genuinely slow, or waiting for interactive input. Composer prompts on an unresolvable plugin allow-list or a VCS authentication question, and a prompt with no terminal waits forever.

PHP tooling is full of interactive prompts. composer require will ask before allowing a new plugin. composer create-project asks about removing VCS history. A Symfony console command with a confirmation question does the same. Run any of those non-interactively and the process sits there with an unanswered question written to a terminal nobody is reading. Atlas's bash tool races every command against a timeout, so instead of a session that appears frozen you get a killed process and a shell_metadata block explaining what happened. Reading that block is step one: Atlas tells you exactly what happened and what to do, and the message explicitly calls out the interactive-input case, which is what separates the diagnosis from a shrug.

How do I tell if a PHP command is slow or blocked on input?

Read Atlas's timeout message. Atlas says to retry with a larger timeout if the command is expected to take longer and is not waiting for interactive input. Both halves matter. A PHPUnit suite of 4000 tests is genuinely slow. A Composer prompt is blocked, and no timeout value in 2026 will ever be large enough to fix it.

The distinction is the entire diagnosis, and Atlas hands it to you in the message rather than making you infer it. Decide from the message whether the PHP command is slow or blocked: Atlas explicitly calls out the interactive-input case, because a blocked-on-stdin command is the most common cause and it never resolves by waiting. Ask yourself what the process was doing when it died. If the last output line was Loading composer repositories with package information, Composer is working and probably slow. If the last line was a question ending in a prompt marker, Composer is blocked. If there was no output at all, suspect a prompt written to a TTY that Atlas's non-interactive shell never rendered. The read tool then lets you inspect any log file the command wrote before it stalled.

What non-interactive flags unstick a blocked PHP command?

Composer takes --no-interaction, which turns every question into its default answer, and that is the 1 flag that unsticks most blocked PHP commands inside Atlas. CI-style environment variables serve the same role for Symfony console commands and PHPUnit wrappers that shell out to interactive tooling.

The fix for a blocked command is to remove its ability to ask. In PHP that means Composer's non-interaction flag on every install, update, and require you run through Atlas, plus CI mode or --no-input on any framework console command in your project's bin/ directory. The general rule the Atlas workflow gives you is to re-run with the tool's non-interactive flags (-y, --no-input, CI mode) so it cannot prompt. Once the command cannot prompt, a second hang means the command really is slow, and the diagnosis has narrowed to one possibility. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, so a good PHP setup allows the non-interactive Composer invocations and puts the bare interactive ones behind an ask prompt.

How do I raise the timeout for a genuinely slow PHPUnit run?

Atlas instructs you to retry with a larger timeout value in milliseconds when a PHP command is genuinely slow, so 1 minute is 60000 rather than 60. A PHPUnit suite that spins up a database per test case, or a Composer install resolving a large private Satis tree, legitimately runs past the default.

Slow is not broken, and Atlas's timeout message tells you the remedy directly: retry with a larger timeout, expressed in milliseconds. The cases in PHP that legitimately need it are predictable. A full PHPUnit run against a real MySQL database. A Composer install with no warm cache. A PHP-CS-Fixer pass across a large monorepo with thousands of files under src/. Raise the timeout for those specific commands rather than globally, so a genuinely stuck command still surfaces quickly everywhere else. Atlas's bash tool saves large output to a file you can read when it exceeds the limits, so a long PHPUnit run's output is not lost to truncation, and the read tool retrieves the full log afterwards.

How do I tell my own interrupt apart from a timeout in Atlas?

Atlas's shell_metadata block says User aborted the command when you interrupted the PHP command yourself, which distinguishes your interrupt from a timeout. That is the 1 detail that matters when you cancel a slow Composer install and then need to know whether the process died on the timeout or on your keypress.

Three outcomes look similar at a glance and mean completely different things: the command timed out, the command failed, and you cancelled it. Atlas's bash tool separates them in the shell_metadata block. User aborted the command means your interrupt, not a hang. A timeout message means the timeout expired, and then the slow-versus-blocked question applies. A non-zero exit code with output means the PHP command ran and failed on its own terms, which is a different bug entirely. Knowing which one you are looking at prevents the classic wasted hour of raising a timeout for a command that was never actually timing out. Atlas drafts a plan in a read-only plan agent and asks before switching to a build agent, so nothing in your Composer project changes while you are still diagnosing.

Step by step

01Run the PHP command through Atlas's bash tool and read the shell_metadata block in the output when it is killed.
02Decide from the message whether the command is slow or blocked: Atlas explicitly calls out the interactive-input case, which is the most common cause of a hanging Composer run.
03If it is blocked, re-run with the tool's non-interactive flags (-y, --no-input, CI mode) so it cannot prompt, for example Composer's non-interaction flag on install and require.
04If it is genuinely slow, retry with a larger timeout value in milliseconds, as the message instructs, for a full PHPUnit suite against a real database or a cold Composer install.
05Use the read tool to inspect any log file the PHP command wrote before it stalled, and the file Atlas saves when output exceeds the limits.
06If you aborted the command yourself, note that the metadata says User aborted the command, which distinguishes your interrupt from a timeout.
07Raise timeouts per command rather than globally, so a genuinely stuck PHP-CS-Fixer or PHPUnit run still surfaces quickly everywhere else.

Frequently asked questions

why does composer install hang when an ai agent runs it: Composer is almost certainly blocked on an interactive prompt, for example a plugin allow-list question or a VCS authentication prompt, with no terminal to answer it. Atlas's bash tool races the command against a timeout so the hang surfaces, and the message explicitly calls out the interactive-input case.
how do i know if my php command is slow or stuck: Read Atlas's shell_metadata block. Atlas says to retry with a larger timeout only if the command is expected to take longer and is not waiting for interactive input. A blocked-on-stdin command never resolves by waiting, so if the last output was a question rather than progress, it is blocked.
what non-interactive flag stops composer from prompting: Composer takes a non-interaction flag that turns every question into its default answer. The general Atlas guidance is to re-run with the tool's non-interactive flags (-y, --no-input, CI mode) so it cannot prompt. Once the command cannot prompt, a second hang means it is genuinely slow.
how do i increase the bash timeout in atlas for a slow phpunit run: Retry with a larger timeout value in milliseconds, as Atlas's message instructs. A full PHPUnit suite against a real database legitimately runs past the default. Raise the timeout for that specific command rather than globally, so a genuinely stuck command still surfaces quickly everywhere else.
does atlas lose output from a long php command: No. When output exceeds the limits, Atlas's bash tool saves the full log to a file you can read with the read tool. So a long PHPUnit run or a verbose PHP-CS-Fixer pass across src/ leaves a complete record rather than a silently truncated one.
what does user aborted the command mean in atlas: It means you interrupted the process yourself, not that it timed out. Atlas's bash metadata distinguishes your interrupt from a timeout and from a non-zero exit code, which prevents the wasted effort of raising a timeout for a PHP command that was never actually timing out.
can atlas diagnose a hanging symfony console command: Yes. Run it through the bash tool, read the shell_metadata block when it is killed, and check whether the message points at interactive input. Framework console commands in bin/ prompt on confirmation questions, so the fix is usually a --no-input or CI mode flag rather than a longer timeout.
will atlas change my php code while diagnosing a hang: No. Atlas drafts a plan in a read-only plan agent and asks before switching to a build agent, and every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs. Diagnosing a hang uses only bash and read, neither of which writes to your Composer project.

Try Atlas in your terminal

The terminal-native AI coding agent. Free core, single binary.

Install Atlas

Related guides

Diagnose a Hanging or Long-Running Command with Atlas in 2026

How to diagnose a hanging command with Atlas in 2026: the bash tool races every command against a timeout and tells you whether it is slow or blocked on input.

Atlas for PHP in 2026

Atlas, the terminal-native AI coding agent, empowers PHP developers in 2026 with intelligent code understanding, secure workflows, and direct integration for Composer and PSR standards.

Extract a shared helper from duplicated code in PHP with Atlas (2026)

The same PHP logic is copy-pasted in 5 controllers with different variable names. Atlas finds it by meaning with codebase_search, extracts one helper, and proves it with PHPUnit.

Self-review your working diff before committing in PHP with Atlas in 2026

Catch your own mistakes in PHP code before they reach a reviewer or CI. Atlas helps PHP developers in 2026 self-review uncommitted diffs, run PHPUnit tests, and apply PHP-CS-Fixer formatting.

Write unit tests for untested code in PHP with Atlas (2026)

Write PHPUnit tests for untested PHP code in 2026 with Atlas: enumerate exported symbols with documentSymbol, copy the repo's test conventions, then actually run them.

Add a regression test for a bug fix in PHP with Atlas (2026)

Add a PHP regression test for a bug fix in 2026: Atlas proves the PHPUnit test fails red first, applies the fix with edit, and re-runs the same command to prove green.

Debug a Single Failing Test in PHP with Atlas (2026)

Debug one failing PHPUnit test with Atlas in 2026: isolate it with the filter flag, walk the call path with the lsp tool, and fix the PHP code, not the assertion.

Plan a multi-file change before editing in PHP with Atlas (2026)

Design a multi-file PHP change before any edit lands. Atlas's plan agent denies edit outside .atlas/plans/*.md, and plan_exit gates the handoff to the build agent.

Browse this resource hub