Long Command Check
For people building agents. The question is simple: when the agent runs a shell command, should it wait for it to finish? Following that question leads to a chain of design decisions. Foreground is for fast commands, background is for long ones, and ideally the same process connects the two.
Companion to MCode Engineering Notes 04, "How long should one bash command
wait". Plain-text checklist: checklists/long-command.md.
Why waiting is expensive
Two costs while the agent blocks on a command:
- The visible one: the user waits and nothing else happens.
- The hidden one: the provider's prompt cache can expire. While a command runs in the foreground there are no new model requests. If the wait is longer than the cache lifetime of the model service you use, the next request re-processes the whole prefix: slower first token, higher cost. Look up the cache lifetime in your provider's documentation.
Moving work to the background does not keep the cache warm forever. It saves the time the agent would otherwise spend idle when it had other work to do.
How to run the audit
Read the shell tool and background-task code of the target agent. For each item, record the answer with evidence (file and function, config, or a test you ran). Do not guess; write "unknown" if the code does not show it.
| # | Item | Question |
|---|---|---|
| 1 | Foreground limit | How long does the foreground wait at most? Is that comfortably below the cache lifetime of your model service, leaving room for generation time? |
| 2 | No re-run | When a command moves from foreground to background, is it the same process, or is it killed and started again? |
| 3 | Timeout accounting | After moving to background and reading output, is the deadline reset? (It should not be, or a stuck command can run forever.) |
| 4 | Result delivery | When a background task finishes, does the model learn it from a notification, or only by polling? |
| 5 | Notification position | Is the notification appended at the end, or does it modify an already cached prefix? |
| 6 | Anti-polling | Is blocking wait time capped, and does repeated reading with no change produce a hint to stop polling? |
| 7 | Output size | Is large output truncated or written to a file and read incrementally, rather than pasted whole into context? Is incomplete output labelled as incomplete? |
| 8 | Cleanup | Who stops background tasks when the user stops the agent, when a one-shot headless run exits, and when the process restarts? Are orphaned tasks marked instead of showing "running" forever? |
| 9 | After compaction | Is "a task finished and its result was not read" tracked outside the conversation history (for example a task table), so it survives compaction? |
| 10 | Precondition | If the current environment cannot read background results, is backgrounding disabled? |
Quick behavioural tests
If you can run the agent, try these and record what actually happened:
- Ask it to start a dev server and then do something else. Does it hang?
- Run a command that takes several minutes. Does it move to the background without starting a second copy?
- Start a background task, then stop the agent. Is the task stopped?
- Let a background task finish, then trigger compaction before reading the result. Is the unread result still surfaced afterwards?
Output
A table of the ten items with pass / fail / unknown and evidence, the results of any behavioural tests, and the top three fixes.
