Skip to content

1.4.1

Latest

Choose a tag to compare

@github-actions github-actions released this 20 Oct 16:24
· 1 commit to main since this release

中文说明 / Chinese release notes: 1.4.1_CN.md

Version 1.4.1

Release Date: October 21, 2026

Overview

Version 1.4.1 includes the approval and question changes introduced in 1.4.0, plus Windows compatibility and first-run logging fixes.

The 1.4 series changes how approvals and questions are handled from WeChat, WeCom, and Telegram.

  • One auto-approval policy for Codex, Claude Code, and OpenCode. Routine work inside the project runs without interruption. Destructive commands, operations that act outside your machine, writes outside the workspace, and MCP tool calls are sent to you for confirmation.
  • Automatic approvals are reported. The reply tells you what was approved automatically during the turn, and /auto on|off switches the policy while the daemon runs.
  • More approval replies. /always allows similar requests for the rest of the session, /deny <reason> tells the model why, and /abort denies and stops the turn.
  • Plain replies answer questions. While a CLI waits for an answer, any message that does not start with / is the answer. Several questions are asked one at a time.

The release also fixes five problems: the bridge replaced your own Codex approval and sandbox settings, answered Codex requests that belonged to the local terminal, kept Claude Code approvals open after you answered them in the terminal, sometimes left the WeChat "typing…" status on after the reply, and paused the daemon for hundreds of milliseconds when the Codex session history was large.

Fixes in 1.4.1

  • Windows Git Bash commands keep their expected approval behavior. Redirection to shell devices such as /dev/null no longer triggers an unnecessary outside-workspace approval.
  • Logging works before the data directory exists. The bridge creates the log directory before writing, so leaving a Codex request to another local client does not fail with ENOENT on a fresh installation.
  • Approval regression tests use the actual workspace. Coverage checks both allowed writes inside the workspace and approval requests for writes outside it, using native paths on each platform.

Approvals

One Policy for Three CLIs

Before 1.4.0 each CLI followed its own rule: Codex approved every command not on a high-risk list and every file change; Claude Code allowed every tool except high-risk shell commands, including MCP tools and writes to any location; OpenCode never approved anything automatically. All three now follow the same policy.

Sent to you for confirmation:

Category Examples
Destructive local commands rm, sudo, dd, git reset --hard, git clean -f, git checkout -f, git restore, git branch -D, git stash drop, chmod -R, kill -9, pkill, curl … | sh
Commands that act outside your machine git push; publishing with npm, pnpm, yarn, bun, cargo, or gem; twine upload; docker push and docker login; gh release, gh pr create/merge/close, gh repo changes, gh workflow run; deploy, vercel --prod; kubectl apply/delete; terraform apply/destroy; pulumi up; helm install/upgrade; writes with aws s3; ssh, scp, sftp, and rsync to a remote host
Writes outside the workspace A command that writes or redirects to a path outside the project directory; a file change or permission grant outside it
Access outside the workspace An OpenCode request to use a directory outside the project
MCP tools Every MCP tool call
Decisions only you can make Approving a Claude Code plan
Requests the bridge cannot classify Permission types the bridge does not recognize, and commands whose text is not shown

Approved automatically: everything else, including reads, ordinary network access, and file changes inside the workspace. Codex does not say which files a change touches before it is approved, so a Codex file change is approved automatically only when Codex limits it to the workspace.

The policy applies only to requests a CLI sends for approval. If a CLI is configured to run without approvals, its actions never reach the bridge.

Automatic Approvals Are Reported

When requests were approved automatically during a turn, the final reply includes one line before any attachments, for example:

Auto-approved this turn: 2 command(s), 1 file change(s)

Counts are grouped into commands, file changes, permission grants, network requests, reads, and other requests, and start again from zero with each turn.

/auto

Command Effect
/auto Show whether auto-approval is on
/auto on Turn auto-approval on for every window
/auto off Send every approval request to you

The setting lasts until the daemon exits. At startup, auto-approval is on unless the daemon was started with CLI_BRIDGE_STRICT_APPROVAL=1.

Approval Replies

Reply Effect Available for
/confirm, /yes, confirm, yes Allow this request All CLIs
/always Allow this request and similar ones for the rest of the session; your settings files are not changed Codex, when the request offers session approval; Claude Code, when it suggests a permission rule
/deny, /no, deny, no Deny this request All CLIs
/deny <reason> Deny and give the model your reason Claude Code and OpenCode receive the reason with the denial; Codex receives it as the next message after the turn ends
/abort Deny and stop the current turn Claude Code and OpenCode; Codex, when the request allows cancellation

Each approval message lists only the replies that work for that request and says how many more requests are waiting. A reply the request does not support is refused with a hint, for example to send /deny and then /stop. OpenCode's own "always allow" option saves a permanent project rule, so /always is not offered for OpenCode.

Questions

When Claude Code, Codex, or OpenCode asks you a question:

  • Any message that does not start with / is the answer. Previously, plain messages were blocked until you used /answer; /answer still works.
  • Choose options by number or by their exact label. For multiple choice, separate choices with commas (, or ,), 、, or spaces, for example 1 3.
  • Add a note to a choice by writing text after the number, for example 2 not yet.
  • Write your own answer by sending any other text. If the question accepts only the listed options, you are asked to choose again.
  • Several questions are asked one at a time, each marked with its position, such as Question 1/3, and the answers are submitted together after the last one. You can still answer all of them at once as number=answer; number=answer.

The bridge never answers or preselects an option for you. The rules are the same for all three CLIs; previously Codex expected a note after |, and multiple choice accepted only ,.

Bug Fixes

Codex Keeps Your Approval and Sandbox Settings

When the bridge started Codex itself, it set the approval policy to "on request", the approval reviewer to you, and the sandbox to "workspace write" for every new thread, resumed thread, and turn. This replaced settings such as never asking, full access, or automatic review, and could change the settings of a thread shared with the terminal. The bridge no longer sets them: new threads use your Codex configuration, and resumed threads keep their own settings. If your Codex configuration grants full access, remote tasks run without approval requests.

Codex Requests That Belong to the Terminal

Codex sends each request to every window connected to a thread and accepts the first answer. The bridge used to answer all of them at once, so MCP tool calls were rejected even when you were at the terminal. Now:

  • MCP tool approvals are sent to you like other approvals and are answered with /confirm or /deny.
  • Forms, links, and device checks that an MCP server asks you to complete are left to the terminal, and the chat tells you to finish them there.
  • Requests from other threads, and request types the bridge does not handle, are left to the terminal.

Claude Code Approvals Answered in the Terminal

An approval you handled in Claude Code's own terminal dialog stayed open in the chat and blocked plain messages until the turn ended. It now closes as soon as the tool runs, fails, or a new prompt is submitted. A /confirm that arrives before the approval message was delivered no longer approves a request you have not seen; the bridge shows you the current request instead.

WeChat "Typing…" Status

If a turn ended while the "typing…" status was still being turned on, the status could stay on after the reply. The status now:

  • turns off only after every window that started it for that contact has finished;
  • pauses while an approval or question waits for you, and resumes after you reply;
  • turns off on /abort, and when the CLI becomes idle, stops, or reports an error.

Pauses With a Large Codex Session History

To find the current Codex session, the bridge read every file in ~/.codex/sessions completely, although it needs only the first line, and repeated this up to twice a second while waiting for a new session to appear. The daemon could not handle messages during each scan. With 67 session files totalling 1.4 GB, a scan took 280–680 ms; it now reads only the first line of each file and takes 3–12 ms.

Upgrade and Compatibility Notes

Install

New users should install cli-chat-bridge, the project's shorter, upcoming name:

npm install -g cli-chat-bridge@1.4.1

The identical cli-wechat-bridge package is published alongside it:

npm install -g cli-wechat-bridge@1.4.1

@unlinearity/cli-wechat-bridge also receives the same release, so existing installations continue to update:

npm install -g @unlinearity/cli-wechat-bridge@1.4.1

All three packages provide the same commands, so install only one. To switch, uninstall the current package first, for example npm uninstall -g @unlinearity/cli-wechat-bridge; otherwise npm stops with EEXIST.

Restart

Stop running daemons and visible CLI windows, then start them again. Claude Code and OpenCode windows started before the upgrade accept only /confirm and /deny, do not follow /auto, and do not pass a /deny reason until they are restarted. Credentials and saved state need no migration.

Behavior Changes

  • OpenCode now approves routine requests automatically. Previously it sent every request to you. To keep that behavior, send /auto off or start the daemon with CLI_BRIDGE_STRICT_APPROVAL=1.
  • Claude Code asks more often. MCP tools, writes outside the workspace, plan approval, and commands that act outside your machine now need your confirmation.
  • Codex follows your own configuration. With a full-access or never-ask Codex configuration, remote tasks no longer stop for approval.
  • Plain messages answer a waiting question instead of being blocked. To send a command while a question waits, start the message with /.

Requirements

  • Node.js >=22.13.0; Pi requires >=22.19.0.
  • Codex: regular bridging supports 0.149.x–0.161.x; attaching to a running session requires Codex 0.162 or later.
  • Codex MCP forms, links, and device checks are completed in the terminal.

Release Validation

  • On macOS with Node.js 24.20.0 and Bun 1.4.3, npm run quality passes: lint, strict source type checking, all 946 tests, and the build.
  • Regression coverage includes shell device redirections, native workspace boundaries, and logging with a missing data directory.
  • npm pack --dry-run --json lists 133 files, including bin/, dist/, both READMEs, LICENSE.txt, and the Codex bridge skill, without local state or logs.
  • npm run smoke:global -- --purge-global --clean-cache --full installs a real tarball and verifies all 15 launchers outside the repository.
  • npm run smoke:cli-compat passes with Codex 0.163.0, Claude Code 2.1.304, OpenCode 2.0.18, and Pi 1.1.0.
  • npm publish --dry-run --access public and npm run publish:dual -- --dry-run pass for all three package names.

Full Changelog: 1.4.0...1.4.1