Baize: a coding agent CLI that redacts secrets before the model sees them

What Baize actually protects

Baize is described as a security assistant for Vibe Coding and data analysis, and the project name comes from a Chinese mythical beast. Its tagline is a good summary of the design: speak freely, keep secrets sealed.

The core mechanism is bidirectional reversible privacy protection. Sensitive information is replaced with placeholders before being sent to the LLM, and automatically restored after the response is received. The placeholders look like a random token, for example a phone number masked as a string with a PZ_PHONE prefix and a hex suffix.

The documentation is explicit that the whole process is invisible to the user. The history, the tool parameters and the final answers always contain the original text, while the LLM always sees the random, unguessable placeholder. That is the part that makes the approach usable: the model reasons about a placeholder such as PZ_PHONE_a3f8b2c1d4e5f6a7 as if it were the number, so a request like call this number still works.

Around that core there are three more privacy properties. Session files, compressed transcripts and audit logs are automatically redacted before being written to disk, and this is enabled by default, so plaintext PII never appears on disk. The placeholders use 64-bit cryptographic random tokens and cannot be enumerated, forged or replayed, and old placeholders become invalid immediately after switching sessions, which closes the door on a placeholder captured in one conversation being reused in another. And the product has no remote database and runs fully locally, collecting no user information.

The audience is a developer who pastes code and credentials into a hosted model and wants the sensitive parts never to leave the machine.

The redaction list, the modes and how you turn it on

The redaction covers more than thirty types of sensitive information. The documentation names phone numbers, emails, ID cards, passports, bank cards, international numbers, API keys, JWTs, database connection strings and MAC addresses, and the feature list uses the phrase and so on for the remainder.

There are two modes, standard and strict, and you switch between them either by natural language input in the CLI or with the more precise /privacy command. The same choice also exists as a natural language trigger, which is convenient but a poor idea for anything you rely on.

The .env.example file in the repository shows the same care applied to configuration. The keys are all left empty and commented out, so that you only fill in the backend you actually use. The file names DeepSeek as the default backend and points at the platform key page, and it also covers an OpenAI or any OpenAI-compatible endpoint, and names specific providers, with a comment explaining that the base_url is configured in config.toml under the model provider section and not here.

The Ollama entry is the one with no key at all, and the comment is the practical instruction: you only need Ollama running on localhost:11434, no configuration required in that file.

The variable naming rule is stated at the top of that file, and it matters for scripting: the variable name has to match the env_key field in config.toml.

Backends, zero configuration startup and the install path

Baize supports multiple backends and you switch with one configuration change. The list is DeepSeek, any OpenAI-compatible endpoint which covers GLM, Qwen, Kimi and OpenAI, and a local Ollama. The description names Zhipu and Tongyi as well in the provider list, and the .env.example has a separate block for each of them, including a custom gateway option and Ollama for a local model with no key.

Installation needs Python 3.10 or newer, which the README states requires tomllib, and it adds that tomllib is built in from 3.11 while on 3.10 you install tomli. pip is the other prerequisite. The pyproject.toml is stricter than that, with requires-python set to >=3.11, so the packaging metadata and the documentation are not quite aligned on the floor.

Startup is zero configuration in the practical sense: configuration files are generated automatically on first run and you only enter your API key once. The console script is baize, mapped to agent.Baize:main in the entry points, so the command you run is simply baize.

The install from source has two documented routes. The first is a single pip command against the Git URL, pip install https://github.com/Xu123-Bob/Baize.git. The second is to download the ZIP from the Code menu on the repository page, extract it, change into the directory and run pip install -r on the requirements file.

On Windows the documentation describes the launch step as opening a command prompt and then starting the CLI:

    bash -- press Win+R, enter `cmd`, then run:
    baize

The runtime dependencies are short and tell you what it actually uses: openai for the client, httpx, duckduckgo-search for web search, beautifulsoup4 and requests for fetching and parsing, rich for the terminal output, wcwidth for character width handling, tenacity for retries, psutil for process information, and python-dotenv for loading the .env file.

The agent toolchain: skills, subagents, hooks, MCP and the sandbox

Baize is a coding agent rather than a chat wrapper, and the toolchain is the substance.

The complete toolchain is listed as bash execution, file read, write and edit, glob and grep search, web search and fetch, background tasks, and task and todo management. Those are the primitives an agent needs to actually edit a repository rather than describe an edit.

On top of that sit four extension mechanisms. The skill system loads domain knowledge on demand from SKILL.md files, so the assistant can be more professional in a specific scenario. Subagents delegate complex work to agents with independent contexts, which keeps a long exploration out of the main session. Hooks are Python or shell scripts that intercept tool calls before and after, and the documented uses are audit logs, automatic formatting and test gating. The MCP protocol connects to external tool servers, with GitHub and Filesystem named.

Context compression is two level, combining tool result truncation with LLM summarization, so that a long conversation does not run out of room.

The secure sandbox is the part that decides whether you can let an agent run commands. It has a command allowlist, path escape detection, dangerous command blocking, sensitive file protection and script injection interception.

The packaging metadata shows how these are shipped. The package data includes skills and subagent markdown, the hooks directory of Python files, and a directory of MCP server JSON configurations, all under the agent package. The CLI is described as black-gold themed, with Chinese width adaptation, syntax highlighting, diff colouring and collapsible thinking, the width adaptation being the practical part for a multilingual terminal.

The interface itself is in nine languages: Chinese, English, Japanese, Korean, Spanish, French, German, Russian and Arabic. You say English or use /lang ja and the assistant thinks and replies in that language for the session.

Where Baize is the wrong tool

The first limit is that redaction is lossy in a way that matters for reasoning. If you ask an agent to fix a configuration file that contains a connection string, the model sees a placeholder, and any suggestion it makes about that specific value is a guess. The documentation is honest that the skill is the point, but for an agent whose task is to work on secrets directly, masking everything is the wrong default. This is also why the strict mode exists as a separate choice rather than a single always-on behaviour.

The second is that the redaction list is a list, and a list of thirty-plus patterns is a list of thirty-plus known shapes. It covers the common cases, and an unusual identifier format is not on it. The injection resistance argument is that the placeholders cannot be forged or replayed, which is true and is about a different threat, but the coverage question is about whether a secret is recognised at all.

The third is the version floor and the local-first requirement. The packaging requires Python 3.11 or newer, and the agent is a local process with a CLI, so there is no hosted version to point a teammate at and no shared configuration. Every developer on the team runs their own instance with their own keys.

The fourth is that this is a tool with a thin dependency list and a single maintainer, judging by the repository layout with one agent/ directory, one pyproject.toml, and the contributor files in Chinese and English. The repository is not archived and the last push was on 2026-10-18, so it is being worked on, but there is no GitHub issue tracker visible in the tree and no changelog beyond the release tags, with v2.2.0 on 2026-09-29 and v2.7.0 on 2026-10-13.

Compare that with the general purpose coding agents that ship the tool calling, subagents and MCP support already. The difference in approach is that those tools treat the model as the trusted component and focus on the tool layer, while Baize adds a privacy layer underneath and gives up nothing about the tool layer. If your requirement is a working agent with good tooling, the redaction is a differentiator you may not need; if your requirement is that secrets do not reach a third party, it is the reason to choose this one.

Licence, project shape and what to check first

Baize is released under the MIT licence, with the text in the LICENSE file at the repository root and a licence badge in the documentation. The MIT terms are permissive, and for a tool that runs locally on a developer's own machine and talks to whatever backend you point it at, that is the straightforward choice. Read the LICENSE file yourself for the exact terms before you redistribute it inside a company image.

The repository layout is worth a look. There is an agent/ directory holding the package, a pyproject.toml, a MANIFEST.in for the packaging data, an .env.example, and both requirement-data.txt and a file with a misspelled name, requirment.text, which is the kind of duplication that suggests the requirements were assembled by hand rather than derived. The documentation is multilingual, with README.md plus per-language files for Chinese, English, Spanish, French, Japanese, Korean and Russian, and there are also CONTRIBUTOR files in Chinese and English and download instructions in two formats.

The project is mirrored on AtomGit as well as GitHub, and the documentation carries a badge for a Trendshift repository listing, which suggests it has been noticed outside GitHub. There is no homepage recorded for the repository itself.

What to verify first is narrow. Run it against a local Ollama instance so that nothing leaves the machine while you evaluate it, then feed it a session containing one of each kind of secret you actually handle and check the redaction. Turn on strict mode and confirm the model can still complete the task with masked values, because that is the failure point. And check the .env variable names against the env_key fields in your config.toml, since the file states that they must match and nothing in the package enforces it for you.

Editorial conclusion

Baize fits a developer who has to paste proprietary code, credentials or personal data into a hosted model and wants a defensible answer to where that data goes, since the redaction happens on the client side before the request is built. It does not fit a team that wants a model to see unredacted context, since every phone number, API key and connection string in the conversation is masked, and it does not fit someone who cannot run a local Python process. Before adopting it, check the thirty-plus redaction patterns against the kinds of secrets in your own repository, confirm your chosen backend is one of the supported ones, and read the strict mode behaviour before turning it on for a session where you need the model to reason about an actual key.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. Xu123-Bob/Baize on GitHub