commands

CLI commands for inspecting the configuration surface.

Bare config resolves each option against the app credential store (for credentials), the live environment, and config.toml, reporting the effective value and which source provided it. config get <key> reports the same for a single option, and config get <section> — a dotted key prefix such as credentials, matched case-insensitively — renders every option under that prefix using the same grouped view as bare config. Adding --verbose/--all to any of the three folds in each option's description and where it can be set (the static catalog). config path prints the on-disk config locations.

Secret-flagged options (API keys and other credentials) are never printed by value — config/config get report only whether they are set and from which source, so the output is safe to paste into a bug report.

Help rendering for config -h is served by ui.show_config_help. The heavy manifest/runtime imports here are function-local, so help never pulls them onto the startup path (parse_args imports this module to register the parsers, but only its light top-level imports run then).

CLI commands for the auth group: manage stored provider credentials.

These subcommands mirror the in-TUI /auth modal verbs so credentials can be managed non-interactively (dotfile bootstrap, CI, remote boxes) without launching the Textual app:

• auth list — one row per known provider with its resolution status.
• auth set <provider> — store an API key read from stdin (preferred) or, with --from-env VAR, copied from a process environment variable.
• auth remove <provider> — delete a stored credential (aliases rm/delete).
• auth status <provider> — print the resolution source (stored, env: VAR, missing, ...) for one provider.
• auth path — print the resolved auth.json path.

Security notes:

• The key value is never echoed, logged, or printed back. set defaults to reading from stdin so the key never lands in shell history or argv, and it refuses an interactive TTY (use --from-env instead) so an accidental invocation cannot hang waiting on input.
• set and remove route through auth_store, so chmod warnings from the store rewrite (the same path the TUI uses) are surfaced on stderr.

Help rendering for a bare auth invocation is served by ui.show_auth_help, which does not import this module. The heavy model_config imports here are function-local so a bare auth/auth -h invocation stays on the startup fast path (parse_args imports this module only for its light top-level imports).

CLI install path for optional deepagents-code extras.

dcode install <name> installs a curated optional extra (for example a sandbox or model-provider dependency) into the current dcode environment. The legacy global flags dcode --install <name> / --package / --yes remain as compatible aliases and call the same implementation.

tools install is intentionally separate: that group provisions managed host binaries (ripgrep), while this command manages Python package extras for dcode.

Help rendering for dcode install -h is served by ui.show_install_help, which does not import this module, so the help path stays light.

The dcode tools command group: provision managed external tools.

dcode tools install fetches the pinned, SHA-256-verified ripgrep binary into ~/.deepagents/bin (the same managed path used on first run) and is also handy for repairing a missing or stale rg. The install script calls this verb instead of re-encoding the pinned version + checksum table in bash.

dcode tools list prints the tools available to the agent, grouped by source (built-in tools, then per-server MCP tools), enumerated from the real tool objects the agent binds so the output never drifts from what the model sees.

Help rendering for dcode tools -h / dcode tools install -h / dcode tools list -h is served by ui.show_tools_help / ui.show_tools_install_help / ui.show_tools_list_help, which do not import this module, so the help path stays light.

CLI commands of the MCP module.