qybaihe/mu is a coding agent built on top of pi and AionUi. The large model performs the actual work, while a small judge model handles the routine decisions that end in a yes/no. The 2026-10-25 commit 4d5c0fd merged PR #234 from the release/v0.2.11 branch and shipped mu-agent 0.2.11. The desktop app's package.json version and muAgentVersion both went up from 0.2.10 to 0.2.11, and the app license is listed as MIT AND Apache-2.0.
The change that stands out in this release is that judge mode (judge mode) stopped asking for approval for read-only git commands. Some models prefix every command with cd <project folder> &&, but until now mu counted every git command following cd as a command that could change something. As a result, even cd /path/to/project && git diff was sent to the judge, and when the judge was not confident the confirmation fell to the user. Now, when you cd into the folder where the conversation was opened, git stays read-only, and when you cd somewhere else it asks for confirmation as before. The cd path must be written starting from the root, notations such as ../ or ~ cannot be used, and links are resolved. Commands that only show a list, such as git branch --show-current, git branch -a, git tag -l, git remote -v, git stash list, git worktree list, git config user.name and --get, git grep, git rev-list, git ls-tree, git cat-file, now also run without asking. The site also gained release descriptions in English, Japanese, Korean, Simplified Chinese, and Traditional Chinese.
Commands that modify, delete, or execute remain confirmation targets as before. Commands such as git branch x, git stash, git -c … log, and git grep -O still go through the judge this time as well. Since the read-only determination (isReadOnlyChain) is the determination shared by the permission gate, the constraint gate, and checkpoints, a bg_start given a cwd outside the conversation folder now treats git as a change. Previously, bg_start {command: "git status", cwd: "/elsewhere"} passed as read-only. That said, the commit contains no measurement of how much the approval procedure shrank, and no user count either. It is close to a narrow patch that reduces the friction of the confirmation prompt, not a feature that removes approval itself.