mirror of
https://github.com/hanzoai/dev.git
synced 2026-10-17 15:34:54 +00:00
zeekay
901a81abe9
The docs read as OpenAI's Codex CLI: a getting-started page titled for it, `codex --enable skills` and `code sandbox macos` for commands that do not exist, defaults given as gpt-5.1-codex-max/openai when they are zen5-coder/hanzo, a Homebrew page describing a formula we do not publish. Removed three tui-stream-chunking notes and the execpolicy page: they document modules and a subcommand that live only in the vendored upstream copy. There is no execpolicy subcommand and no .codexpolicy loader in code-rs; the page told users to run something the binary does not have. Rewrote tui-alternate-screen against the source. It described an auto/always/never enum and a --no-alt-screen flag; the shipped behavior is a tui.alternate_screen bool with Ctrl+T, which replays the transcript into scrollback on the way out — a better answer to Zellij than the one written down. Genuine openai-provider documentation stays.
94 lines
3.7 KiB
Markdown
94 lines
3.7 KiB
Markdown
## Advanced
|
|
|
|
## Non-interactive / CI mode
|
|
|
|
Run Hanzo Dev headless in pipelines. Example GitHub Action step:
|
|
|
|
```yaml
|
|
- name: Update changelog via Dev
|
|
run: |
|
|
npm install -g @hanzo/dev
|
|
export HANZO_API_KEY="${{ secrets.HANZO_API_KEY }}"
|
|
dev exec --full-auto "update CHANGELOG for next release"
|
|
```
|
|
|
|
### Resuming non-interactive sessions
|
|
|
|
You can resume a previous headless run to continue the same conversation context and append to the same rollout file.
|
|
|
|
Interactive TUI equivalent:
|
|
|
|
```shell
|
|
dev resume # picker
|
|
dev resume --last # most recent
|
|
dev resume <SESSION_ID>
|
|
```
|
|
|
|
```shell
|
|
# Resume the most recent recorded session and run with a new prompt
|
|
dev exec "ship a release draft changelog" resume --last
|
|
|
|
# Alternatively, pass the prompt via stdin
|
|
# Note: omit the trailing '-' to avoid it being parsed as a SESSION_ID
|
|
echo "ship a release draft changelog" | dev exec resume --last
|
|
|
|
# Or resume a specific session by id (UUID)
|
|
dev exec resume 7f9f9a2e-1b3c-4c7a-9b0e-123456789abc "continue the task"
|
|
```
|
|
|
|
Notes:
|
|
|
|
- When using `--last`, Dev picks the newest recorded session; if none exist, it behaves like starting fresh.
|
|
- Resuming appends new events to the existing session file and maintains the same conversation id.
|
|
|
|
## Tracing / verbose logging
|
|
|
|
Because Dev is written in Rust, it honors the `RUST_LOG` environment variable to configure its logging behavior.
|
|
|
|
When you run the TUI with `--debug`, log messages are written to `~/.code/debug_logs/codex-tui.log`, so you can leave the following running in a separate terminal to monitor log messages as they are written:
|
|
|
|
```
|
|
tail -F ~/.code/debug_logs/codex-tui.log
|
|
```
|
|
|
|
When you enable the CLI `--debug` flag, request/response JSON is partitioned
|
|
into helper-specific folders under `~/.code/debug_logs/`. Expect
|
|
subdirectories such as:
|
|
|
|
- `auto/coordinator`
|
|
- `auto/observer/bootstrap`
|
|
- `auto/observer/cadence`
|
|
- `auto/observer/cross_check`
|
|
- `guided_terminal/agent_install_flow`
|
|
- `guided_terminal/upgrade_terminal_flow`
|
|
- `tui/rate_limit_refresh`
|
|
- `ui/theme_spinner`
|
|
- `ui/theme_builder`
|
|
- `cli/manual_prompt`
|
|
|
|
Tags become nested path components, so custom helpers appear alongside the
|
|
existing timestamped filenames.
|
|
|
|
Without `--debug`, Dev only writes critical crash/error logs to
|
|
`~/.code/debug_logs/critical.log.*`; routine log output is suppressed.
|
|
|
|
By comparison, the non-interactive mode (`dev exec`) defaults to `RUST_LOG=error`, but messages are printed inline, so there is no need to monitor a separate file.
|
|
|
|
See the Rust documentation on [`RUST_LOG`](https://docs.rs/env_logger/latest/env_logger/#enabling-logging) for more information on the configuration options.
|
|
|
|
## Model Context Protocol (MCP)
|
|
|
|
Dev can be configured to leverage MCP servers by defining an [`mcp_servers`](./config.md#mcp_servers) section in `~/.code/config.toml` (Dev will also read a legacy `~/.codex/config.toml`). It is intended to mirror how tools such as Claude and Cursor define `mcpServers` in their respective JSON config files, though Dev's format is slightly different since it uses TOML rather than JSON, e.g.:
|
|
|
|
```toml
|
|
# IMPORTANT: the top-level key is `mcp_servers` rather than `mcpServers`.
|
|
[mcp_servers.server-name]
|
|
command = "npx"
|
|
args = ["-y", "mcp-server"]
|
|
env = { "API_KEY" = "value" }
|
|
```
|
|
|
|
## Using Dev as an MCP Server
|
|
> [!TIP]
|
|
> It is somewhat experimental, but Dev can also be run as an MCP _server_ via `dev mcp`. If you launch it with an MCP client such as `npx @modelcontextprotocol/inspector dev mcp` and send it a `tools/list` request, you will see that there is only one tool, `dev`, that accepts a grab-bag of inputs, including a catch-all `config` map for anything you might want to override. Feel free to play around with it and provide feedback via GitHub issues.
|