Avoid unrealistically short first-attempt timeouts for long-running commands

Summary

Across multiple Jcode sessions, the agent often appears to run a potentially long-running command with an unrealistically short timeout on the first attempt, causing an avoidable failure, then reruns the same command with a more appropriate timeout and succeeds.

This creates noisy failures and can mislead users into thinking the underlying command, service, or authentication failed.

Example observed behavior

During a DockerHub image push, the agent started:

docker push andwalk/simplefps-server:dev

as a background command with a 1000ms timeout. The command failed with exit code 124 after one second while Docker was still waiting/pushing layers.

The agent then reran the same command with a realistic timeout and it completed successfully in about 10 seconds.

Why this matters

For users, the first failed attempt looks like a real operational failure. This is especially confusing for commands such as:

• docker push
• docker build
• Unity builds
• package installs
• test suites
• cloud/registry operations

The false failure adds cognitive overhead and undermines confidence in the tool.

Expected behavior

Jcode should choose conservative default timeouts based on command category, especially for background tasks and known long-running operations.

Suggested rough defaults:

• quick inspection commands: 5-30 seconds
• docker push: 10-15 minutes
• docker build: 10-30 minutes
• Unity builds/imports: 20-60 minutes
• package installs: 5-30 minutes
• test suites: project-dependent, but generally more than 1 second

Alternatively, the harness could warn or clamp when an agent sets an obviously too-short timeout for commands matching known long-running patterns.

Possible mitigations

1. Add command-category timeout hints in the agent policy/prompt.
2. Add harness-level timeout linting for known long-running commands.
3. If run_in_background=true, avoid accepting sub-5-second timeouts unless explicitly marked as a probe.
4. Improve failure labeling so command timeout is visually distinguished from command failure.

Notes

This may be primarily an agent behavior issue rather than a harness bug, but it has been observed across multiple sessions, so it may be worth addressing at the system/policy level.

No source files or tests are named in the issue. Start by tracing how command timeouts are selected for background execution, then compare the policy or harness behavior against the listed long-running command cases; done means avoiding the 1000ms first-attempt failure or clearly distinguishing timeout failures.