Approval on your phone, on every platform — and the version numbers across the CLI, the Mac app and the VS Code extension now line up.
About the version
Codeep V3 is one release across three surfaces, so the three carry one number. The CLI moves 2.25.0 → 3.0.0, the VS Code extension 2.9.0 → 3.0.0, and the Mac app 1.14.0 → 3.0.0. Nothing here is a breaking change — the major is the alignment, said out loud rather than left to look like an accident. The GitHub Action keeps its own v1.x line: it is a separate product with its own consumers and its own supply-chain pinning.
Added
- Answer a confirmation from your phone, over Telegram. When a run stops on
a dangerous tool it waits — and if you have walked away, it waits for as long as you are gone. Connect a bot with /telegram and the same question arrives on your phone with the same three answers. Whichever you use first decides; answering in the terminal takes the message down rather than leaving buttons that no longer do anything, and answering on the phone closes the terminal dialog without running either of its callbacks.
This is where Telegram earns its keep. The Mac app can carry approvals through the user's own iCloud; Linux and Windows have nothing of the sort. The bot API is polled outbound, so there is no server to host and no inbound port to open, and the same code works everywhere the CLI does.
Only the chat ID you configure can answer. A bot's username is discoverable, and without that check anyone who found yours could approve a destructive command on your machine. A late tap cannot reopen a settled question either — each message carries a token matched against the question actually in flight.
Interactive runs only. A headless run — codeep review --fix, ACP, CI — has nobody to ask, and blocking one on an answer that cannot come would hang a pipeline. Those paths are untouched and still decide from agentConfirmation.
The token goes in your OS keychain; the chat ID is ordinary config. Telegram necessarily sees the command, because you cannot judge what you are approving otherwise — which is why this is off by default.
Fixed
- The confirmation showed the binary, not the command. It read
parameters.command, which is git where the truth is git status — asking someone to approve a command they had not been shown, which is the one thing this gate must not do. The same truncated string went to the phone. The audit record already joined the binary with its arguments; that is now what both use.
- A Telegram send that failed said nothing. A wrong chat ID was
indistinguishable from a phone nobody picked up. Telegram's own words are now surfaced, and the failure people actually hit while setting this up is translated into what to do about it.
- The Telegram toggle wrote a value its own getter could not read. Its
options were the strings 'true' and 'false' while the getter returned a boolean, so the setting reported "On" and read false immediately afterwards, forever. Every select in the settings list is now checked against the value it reads back.
All three were found by using it, not by testing it.