Goal Hive can silently hang when launched with unsupported --goal argument

[HamsteRider-m]

Summary

Goal Hive can fail silently when the master process is launched with an unsupported --goal argument instead of the reflect-mode entrypoint. In the observed run, the BBS server stayed alive, but the master never dispatched work and workers eventually exited, making the TUI look like it was frozen.

This appears to be a fail-silent CLI / launch hardening issue rather than only operator error: agentmain.py currently uses parse_known_args(), so unsupported arguments can be swallowed and the process can fall through into interactive mode instead of failing fast.

Observed behavior

• A Goal Hive run was started with a BBS board and workers.
• The master process command line contained agentmain.py --goal ....
• agentmain.py does not define a --goal mode, but the unknown argument was accepted by parse_known_args().
• The process did not print a clear startup error or exit non-zero.
• Instead, it behaved like an interactive agent waiting for stdin in the background.
• The BBS board remained at only the initial post for a long time; no master dispatch appeared.
• Workers had no actionable dispatch and exited / idled, while the TUI looked stuck.

Expected behavior

Goal Hive startup should fail loudly or self-diagnose when the master is not launched through the supported reflect entrypoint.

At minimum:

• agentmain.py --goal ... should not be silently accepted if --goal is unsupported.
• Unknown CLI arguments should only be accepted when they are intended as reflect-script key/value args under --reflect.
• A background Goal Hive launch should surface a clear diagnostic if no master dispatch appears shortly after startup.

Current code shape

Relevant points from the current repo:

• agentmain.py defines --task, --reflect, --input, --llm_no, --verbose, and --nobg.
• agentmain.py then calls parse_known_args() and converts unknown args into _reflect_args.
• Reflect mode is entered only when args.reflect is set.
• Goal Hive SOP / working launches use the reflect entrypoint, e.g.:

python agentmain.py \
  --reflect reflect/agent_team_master.py \
  --base_url http://127.0.0.1:PORT \
  --board_key BOARD_KEY \
  --name hive-master

Suggested fixes

1. Add an argument guard in agentmain.py:

   • if unknown args are present without --reflect, print an error and exit non-zero;
   • optionally special-case --goal with a message that Goal Hive must use --reflect reflect/agent_team_master.py or the supported Hive launcher.

2. Restrict reflect extra args parsing:

   • keep allowing reflect-script key/value args only when --reflect is active;
   • validate odd-length unknown arg lists instead of silently dropping malformed keys/values.

3. Add Goal Hive launch health checks:

   • after startup, verify BBS post count grows beyond the initial post;
   • verify the master publishes a dispatch within a short timeout, e.g. 30-60 seconds;
   • if not, print a clear startup failure instead of leaving the operator with a frozen-looking TUI.

4. Ensure detached long-running master/worker processes are fully TTY-independent:

   • stdin=subprocess.DEVNULL;
   • stdout/stderr redirected to logs;
   • start_new_session=True on Unix/macOS where appropriate.

Reproduction sketch

python agentmain.py --goal /path/to/goal_state.json --base_url http://127.0.0.1:PORT --board_key KEY

Expected: unsupported mode error / non-zero exit.

Observed: the process can continue as a background interactive agent, while Goal Hive BBS receives no master dispatch.

Related but distinct issue

This is different from #536, which is about stale budget state when resuming an interrupted Goal Hive run. This issue is about unsupported CLI arguments being accepted and causing a silent startup hang before dispatch begins.