# Diagnose a hanging or long-running command in Java with Atlas (2026) > Atlas diagnoses a hanging Maven command by reading the bash shell_metadata block: a Java build blocked on stdin never resolves by waiting, so a bigger timeout is the wrong fix. To diagnose a hanging or long-running Java command with Atlas, read what the bash tool tells you when it kills the process. 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 Java build that is blocked on stdin, Maven waiting for a GPG passphrase, a plugin prompting for a version number, a Gradle daemon asking to accept a license, will never resolve by waiting, so retrying with a bigger timeout wastes another 10 minutes. Atlas reads the shell_metadata block in the output, decides between slow and blocked, re-runs with non-interactive flags when the command can prompt, and only raises the timeout in milliseconds when JUnit 5 via mvn test is genuinely just slow. ## Key takeaways - Atlas's bash tool races every Java command against a timeout and tells you exactly what happened and what to do when it expires. - A Maven build blocked on stdin, a GPG passphrase, a versions prompt, a credential lookup, never resolves by waiting, so a larger timeout is the wrong fix. - The shell_metadata block is where the diagnosis lives, and User aborted the command distinguishes your own interrupt from a timeout. - Re-run a blocked Java build with non-interactive flags (-y, --no-input, CI mode) to turn a silent hang into a readable failure. - Only raise the timeout in milliseconds when the command is genuinely slow, for example JUnit 5 via mvn test across a large multi-module reactor. ## Why does my Maven build hang under an AI coding agent? A Maven build hangs under an agent for one of two reasons, and Atlas's bash tool distinguishes them. Either JUnit 5 via mvn test is genuinely slow, or the Java build is silently blocked on interactive input. Atlas races every command against a timeout and, when it expires, tells you which case you are in. Maven is unusually good at blocking on stdin. The gpg plugin prompts for a passphrase during a release. The versions plugin prompts for a new version. A Maven archetype prompts for the groupId. A dependency resolution against a private repository prompts for credentials. In a normal terminal you see the prompt and you type. Under an agent there is no one to type, and the process sits there forever producing no output, which looks exactly like a slow build. Atlas's bash tool does not guess: it races the command against a timeout, and when the timeout expires it reports what happened. The message explicitly calls out the interactive-input case, which is the diagnosis you actually need. ## What is the shell_metadata block in Atlas's bash output? Atlas's bash tool emits a shell_metadata block in its output, and in 2026 that block is the first thing to read when a Java command is killed. The metadata is what distinguishes a timeout from your own interrupt: if you aborted it yourself, the metadata says User aborted the command, which is a different situation from a Maven build that timed out. Three outcomes look similar in a terminal and are completely different in cause. A mvn test run that exceeded the timeout has one story. A mvn test run blocked on a GPG passphrase prompt has another. A mvn test run that you hit Ctrl-C on has a third, and Atlas's metadata says User aborted the command, which distinguishes your interrupt from a timeout. Reading the shell_metadata block rather than the console tail is what keeps the diagnosis honest, because a Java build's console output before a hang is often just a Downloading from central line that tells you nothing about why it stopped. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, so the bash invocation of mvn is one you approved in the first place. ## How do you tell a slow Java build from a blocked one? Atlas decides from the timeout message whether the Java command is slow or blocked, because Atlas explicitly calls out the interactive-input case. Retry with a larger timeout if the command is expected to take longer and is not waiting for interactive input. If it is waiting, a larger timeout in 2026 buys you nothing but another expired clock. The heuristic is about the command, not the clock. A full JUnit 5 via mvn test across a large multi-module Maven reactor legitimately takes many minutes, and the right response is a larger timeout value in milliseconds. A mvn release:prepare, a mvn versions:set, or a Maven build touching a plugin that reads from System.console() can block indefinitely, and no timeout is large enough. Atlas asks which of those two the command is before retrying, because guessing wrong costs a full timeout period. The tell is usually the plugin: anything with release, versions, archetype, or a private-repository credential lookup in the goal is a prompting candidate, while surefire running JUnit 5 tests simply is not. ## How do you re-run a blocked Java command non-interactively? If the Java command is blocked, Atlas re-runs it in 2026 with the tool's non-interactive flags (-y, --no-input, CI mode) so it cannot prompt. For Maven that means batch mode, which turns every interactive prompt into either a default or a hard failure, so a hanging mvn command becomes a loud error you can actually read. Turning a hang into an error is the whole goal. A Maven build in batch mode will not wait for a GPG passphrase; it will fail and say so, and a failure with a message is infinitely more useful than a process sitting at 0 percent CPU. The same principle applies to whatever else the Java build shells out to: pass the CI-mode flag, pass -y, pass --no-input, so the tool declares its need instead of blocking on it. Once the command fails loudly, the actual fix is usually supplying the missing input as an environment variable or a property rather than as a prompt. Atlas reads the resulting error through the same bash tool and proceeds from there. ## How do you set the right timeout for a Java test suite? If a Java command is genuinely slow, Atlas retries with a larger timeout value in milliseconds, as the message instructs. A multi-module Maven reactor running JUnit 5 via mvn test with surefire forking a JVM per module needs a timeout sized to the reactor, not to a single-module project, and Atlas takes that value explicitly. Atlas's bash tool takes the timeout as a number of milliseconds, which means the value is a deliberate choice rather than a hidden default. Size it to the work: a mvn clean install over 12 modules that downloads dependencies, compiles, runs Spotless, and executes JUnit 5 tests is a different scale from mvn test -pl one-module. Getting this right is the difference between a build Atlas can actually observe finishing and one that gets killed at the same point every time, producing a misleading impression of a hang. Once the run completes, Atlas reads the output with the read tool if it was truncated, and the whole diagnosis loop closes. ## Steps 1. Run atlas in a project with a pom.xml or build.gradle so Atlas can read your packages, classpath, and build configuration. 2. Run the Java command through bash and read the shell_metadata block in the output when it is killed. 3. Decide from the message whether the command is slow or blocked: Atlas explicitly calls out the interactive-input case. 4. Check the Maven goal for prompting candidates: release, versions, archetype, or a private-repository credential lookup can block on stdin, while surefire running JUnit 5 via mvn test does not. 5. If it is blocked, re-run with the tool's non-interactive flags (-y, --no-input, CI mode) so it cannot prompt, turning the hang into a loud, readable failure. 6. Supply the missing input as an environment variable or a build property rather than as a prompt, then re-run. 7. If it is genuinely slow, retry with a larger timeout value in milliseconds, sized to the whole Maven reactor rather than to one module. 8. If you aborted it yourself, the metadata says User aborted the command, which distinguishes your interrupt from a timeout, so re-run rather than debug. ## FAQ ### why does mvn test hang forever when run by an AI agent Usually because the Maven build is blocked on interactive input with no one to type. Atlas's bash tool races the command against a timeout and, when it expires, explicitly calls out the interactive-input case so you know a larger timeout will not help. ### how do I tell if a Java build is slow or stuck Read the shell_metadata block in Atlas's bash output. Atlas tells you to 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 whole diagnosis. ### what Maven commands block on stdin Goals involving release, versions, archetype, or a private-repository credential lookup are prompting candidates: they can wait on a GPG passphrase, a version number, or a groupId. Surefire running JUnit 5 via mvn test does not prompt, so a hang there is genuine slowness. ### how do I stop a Java command from prompting under an agent Re-run it with the tool's non-interactive flags (-y, --no-input, CI mode). A Maven build in batch mode will not wait for a passphrase; it fails and says so, and a loud failure is far more useful than a process sitting at 0 percent CPU. ### how do I set a timeout for a long Maven build in Atlas Atlas's bash tool takes the timeout as a value in milliseconds. Size it to the whole reactor: a mvn clean install over 12 modules that downloads dependencies, runs Spotless, and executes JUnit 5 tests needs far longer than a single-module mvn test. ### what does User aborted the command mean in Atlas It is the shell_metadata message that appears when you interrupted the command yourself. It distinguishes your interrupt from a timeout, so you know the Java build was not stuck and can simply re-run it rather than start debugging a hang. ### does Atlas need to see my pom.xml to diagnose a build hang Run atlas in a project with a pom.xml or build.gradle. Atlas reads your packages, classpath, and build configuration, which is what lets it tell a prompting Maven plugin apart from a genuinely slow JUnit 5 via mvn test run. --- Canonical HTML: https://runatlas.sh/resources/stacks/diagnose-a-hanging-or-long-running-command-in-java Source of truth: aeo_pages row `/resources/stacks/diagnose-a-hanging-or-long-running-command-in-java` (segment: Stacks) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.