Gitlawb Zero v0.5.0 shipped on July 22, and it is the kind of release that changes how the tool feels day to day. Instead of one headline feature, this update packs five practical improvements that make the terminal agent easier to use, less disruptive to your workflow, and more flexible for teams that need different sandbox postures. Here is what changed and why each piece matters.
Undo mistakes without losing your place
The most requested quality-of-life feature just landed: /undo now works as an alias for /rewind. If you are new to Gitlawb Zero, /rewind is the command that rolls back your last agent action — file edits, terminal commands, whatever the agent just did. It works like undo in a text editor, except it reverses changes the AI made to your codebase.
Why this matters: before v0.5.0, you had to remember the specific command name /rewind. Most developers think in terms of “undo” — it is the universal shortcut in every editor, IDE, and operating system. Adding /undo as an alias removes a small but real friction point. You no longer have to pause mid-thought to recall whether the command is /undo, /rewind, /revert, or something else. Type what you already know, and it works.
Under the hood, the implementation maps /undo directly to the existing rewind logic, so there is no behavioral difference. Your undone changes go through the same safety checks. The agent’s conversation history stays intact — you can undo an action and then tell the agent to try a different approach.
Ask side questions without breaking your task
The new /btw command lets you spin up an isolated side conversation without interrupting whatever the agent is currently working on. Think of it as a quick aside: the agent is mid-way through refactoring your authentication module, and you want to ask about something unrelated — what a variable does, whether a test file exists, what the deployment config looks like. Before v0.5.0, you had two choices: wait for the current task to finish, or interrupt it and hope the agent remembers where it left off.
/btw creates a separate conversation thread. The agent answers your side question, and then your original task continues exactly where it stopped. The side conversation is isolated — it does not contaminate the main task’s context, and it does not cause the agent to lose track of what it was doing.
This is particularly useful when you are managing a complex task that touches many files. Interrupting to ask a quick question could cause the agent to skip a step or repeat work. With /btw, the main thread stays clean, and you get your answer without tradeoffs.
For beginners: imagine you are having a long conversation with someone about a project plan, and you need to ask a quick unrelated question. You do not want to derail the meeting — you just want a fast answer and then get back to the plan. /btw is that pattern, built into the agent.
Disable the sandbox from your config
Gitlawb Zero runs agent commands inside a sandbox by default — a controlled environment that limits what the agent can access on your machine. This is a core security feature. But not every team needs the same level of restriction. Some development environments require full filesystem access for the agent to work correctly. Before v0.5.0, turning off the sandbox meant passing flags every time you started the agent.
Now you can disable the sandbox through your configuration file. Set the sandbox to disabled in your config, and the agent runs with full access on every subsequent launch. The configuration change is explicit and visible — anyone auditing your setup can see the sandbox posture in the config file rather than having to reconstruct it from shell aliases or wrapper scripts.
This is not a recommendation to turn off the sandbox. The sandbox exists because autonomous agents that run terminal commands need guardrails — a misconfigured agent with full access can delete files, overwrite configurations, or worse. But the project recognizes that some legitimate use cases require unrestricted access, and the right way to handle that is through explicit configuration rather than ad hoc workarounds.
If you are just getting started with Gitlawb Zero, leave the sandbox on. It protects you while you learn what the agent can do and where it needs boundaries. You can always adjust later.
Unified command execution in the sandbox
Under the hood, v0.5.0 unifies how the sandbox handles command execution and enforcement. Previously, different types of commands — file reads, file writes, terminal executions — went through slightly different code paths in the sandbox layer. This created edge cases where a command that should have been blocked slipped through, or where a permitted action was incorrectly denied.
The unified execution model routes all commands through a single enforcement pipeline. Every command gets the same security checks, the same audit logging, and the same permission model. For users, this means more predictable behavior: if you allowed file reads in your sandbox config, all file reads work consistently. If you blocked terminal execution, no variant of terminal access gets through on a technicality.
This kind of infrastructure work is invisible when it is done right — you only notice the problems it solves when they disappear.
Tell the agent why you rejected its command
When Gitlawb Zero asks for your permission to run a command, you previously had two options: approve or deny. Now the permission prompt accepts free-text feedback inline. When you reject a command, you can type a brief explanation of why: “this would overwrite my production config,” “run it in the test directory instead,” or “use sudo for this one.”
The agent uses that feedback to adjust its next attempt. Instead of blindly retrying the same command or guessing what went wrong, it gets direct human guidance about the constraint it violated. This closes the loop between human judgment and agent action — the most valuable interactions with autonomous agents happen when the human can teach the agent their preferences in real time.
For teams, this is especially useful. New team members using the agent for the first time can reject commands and explain their reasoning, and the agent adapts immediately. Over time, this builds a shared understanding between the team’s standards and the agent’s behavior without requiring anyone to write custom rules or configuration files.
Plugin information command
A smaller but welcome addition: zero plugins info lets you inspect installed plugins without leaving the terminal. If you are managing multiple plugins — MCP servers, custom tools, or team-shared extensions — this command shows you what is installed, what version, and what it provides. It is the kind of command you do not need until you do, and then you are glad it exists.
Bug fixes worth noting
v0.5.0 also ships several fixes that improve reliability:
- Session ID probing fix. The agent’s stdin session handling used to probe multiple session IDs in quick succession, causing a burst of unnecessary requests. This is fixed — the agent now resolves the correct session on the first try.
- Provider override warnings. If the
ZERO_PROVIDERenvironment variable overrides a selection you made through the interactive provider menu, the CLI now warns you instead of silently using the environment value. This prevents confusion when your agent seems to ignore your model selection. - Missing binary detection. The built-in doctor command now catches cases where the native binary is missing at runtime and tells you what to do about it, instead of failing with a cryptic error.
How to upgrade
If you are already using Gitlawb Zero, upgrade with:
npm install -g gitlawb-zero@latestAfter upgrading, run the doctor command to verify your installation:
zero doctorCheck the changelog for the full list of changes:
zero --versionWhat this release means
Gitlawb Zero v0.5.0 is not a dramatic rewrite. It is a collection of focused improvements that make the tool more comfortable to use in real workflows. Undo is faster to reach. Side questions do not derail tasks. The sandbox is configurable without flag gymnastics. The agent learns from your rejections.
For the project, this release signals a shift from “build the security fundamentals” to “make the secure agent pleasant to use.” Earlier releases focused on sandbox hardening, trust boundaries, and provider isolation. v0.5.0 takes that foundation and asks: what makes a developer actually want to use this every day?
The answer, it turns out, is the small things. An undo command with a familiar name. A way to ask a question without losing your place. Feedback that the agent actually uses. These are the features that separate a tool you tolerate from a tool you prefer.
If you are evaluating terminal coding agents, Gitlawb Zero’s combination of security-first defaults and increasing usability makes it worth a look — especially if you work on teams where the sandbox and permission model matter as much as the coding itself.