mirror of
https://github.com/multica-ai/multica.git
synced 2026-09-28 13:23:48 +08:00
* fix(agent): pass Hermes custom args before the acp subcommand Hermes only accepts its global flags (--provider, --yolo, -m, ...) ahead of a subcommand, so the daemon's `hermes acp <custom args>` exited with an argparse usage error before the ACP handshake and every run of a Hermes agent with custom_args failed. Assemble `<prefix> <custom args> acp` instead, keep the profile resolver and overlay stripping on the same argv, and drop a trailing custom arg left without its value so it cannot capture `acp` and hang the task in interactive chat. Fixes #8878 (MUL-7748) Co-authored-by: multica-agent <github@multica.ai> * fix(agent): keep acp's own flags after the Hermes subcommand Hermes' acp subparser declares --accept-hooks, --version, --check, --setup, --setup-browser and --yes/-y, and argparse only accepts them after the subcommand: moving them ahead of `acp` turned an agent with custom_args ["--yes"], which launched before, into a usage error. Lay custom args out around `acp` instead — global flags (with their values) before it, acp's own flags after it — and map profile stripping back through that layout so custom args keep their configured order. Co-authored-by: multica-agent <github@multica.ai> * fix(agent): resolve Hermes flag abbreviations like argparse Hermes keeps argparse's allow_abbrev, so custom args must be classified the way its parsers resolve them, not by string equality. Behind `acp` a `--y` is `--yes`; moved in front, the root parser reads it as `--yolo` and turns off dangerous-command approval, while `--ye` went from valid to a usage error. Keep every token the acp subparser would take as its own option (exact, abbreviated or ambiguous) behind the subcommand, and treat abbreviated value flags (`--prov`) as value flags when pairing and when guarding against a bare flag capturing `acp`. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai>