Promote all env vars to clap arguments across cli / api / mcp / viewer

[WiggidyW]

Every binary in the workspace currently sources configuration from environment variables (via envconfig::Envconfig). Each binary should expose those same knobs as native clap CLI arguments so users can set them on the command line without env wrapping. Env-var fallback stays as the secondary source; the CLI arg takes precedence when both are set.

Scope

Four binaries, each ships envconfig-derived Configs today:

• objectiveai-cli — objectiveai_cli::load_config() (see objectiveai-cli/src/config.rs and friends).
• objectiveai-api — objectiveai_api::ConfigBuilder::init_from_env() (driven by the env-config map in objectiveai-api/src/run.rs:140+, ~25+ fields like MOCK_DELAY_MS, MCP_CONNECT_TIMEOUT, FUNCTIONS_INVENTIONS_SUBSCRIBE_TOOLS_TIMEOUT, ADDRESS, PORT, MCP_BACKOFF_*, etc.).
• objectiveai-mcp (objectiveai-mcp-cli) — objectiveai_mcp_cli::ConfigBuilder::init_from_env().
• objectiveai-viewer — objectiveai_viewer::ConfigBuilder::init_from_env().

Each ConfigBuilder enumerates its env vars in one place (clap derive macros on a struct field-by-field, or an explicit map). The clap migration is a per-binary, per-field tweak: add #[arg(long = "...", env = "...")] so clap natively handles both sources with documented precedence.

Suggested approach

1. Per binary: replace the existing #[derive(Envconfig)] struct with a #[derive(clap::Parser)] struct. Each field gets #[arg(long, env = "ENV_NAME")] so:
   • --port 8080 → wins
   • PORT=8080 objectiveai-api → still works
   • Default value: same as today.
2. Drop envconfig + dotenv (or keep dotenv() call at startup so a .env file still hydrates the env, then clap's env attribute picks it up — net behavior unchanged for .env-using developers).
3. Update each binary's main.rs to parse via Parser::parse() instead of init_from_env().
4. Keep all existing env var NAMES so existing deployments don't break.

Why

• Discoverability: objectiveai-api --help should list every knob, not require reading the source.
• Composability: scripting one-off runs is easier without env-var wrapping.
• Test ergonomics: integration tests can pass flags instead of building Command::env(...) chains.

Out of scope

• Renaming env vars.
• Changing the underlying Config struct shape.
• Removing env-var support (it stays as the secondary source).

[WiggidyW]

Closing — fixed in another way.

The premise of the issue was: users set env vars (or have to wrap with --env) to configure api / mcp / viewer. We solved that by removing the user-facing env-var surface entirely, not by promoting each env var to a clap flag.

What changed:

1. Unbundled the binaries (5daf914). The cli no longer embeds the viewer and no longer pulls objectiveai-api as a library — api / mcp / viewer are independent processes.
2. Lifecycle via cli (781ba97). objectiveai {api,viewer,mcp} spawn|kill manages each sibling. Spawn reads <binary>.address + <binary>.port from the on-disk config and stamps them into the child's env; the child's envconfig-driven Config is now fed by the cli, not by the user.
3. jq-style Config subcommand per sibling (d795d37). objectiveai api config get/set, ditto viewer + mcp, lets users edit the on-disk config with the same ergonomics this issue was after — discoverable, scriptable, no env wrapping. The per-knob accessors (objectiveai api address set …, … port set …) are structurally identical across the three siblings.
4. Per-endpoint clap flags where they matter at call time, e.g. --agent-id on api endpoints (8e390ca, 629cf3e) — overrides config + env per invocation.

Net effect:

• --help discoverability: provided by the Config / per-knob subcommands.
• Composability / scripting: objectiveai api address set 0.0.0.0 then objectiveai api spawn, no env wrapping.
• Test ergonomics: integration tests spawn the sibling via the cli (see 781c63a) rather than env-wrapping a Command.

The remaining envconfig deps in the sibling binaries are now an internal contract between the cli (spawner) and each binary (spawnee), not a user-facing surface. Promoting them to clap on each sibling would be churn for no observable user-facing change.

#182 (--no-update flag) is still a real ask and is staying open.