Amenbo 27.0.0 — notifications and worktrees are part of Amenbo
What used to be installed as plugins is now part of Amenbo itself, and a task can be given a git checkout of its own. The changes from 24.3.0, 25.0.0 and 26.0.0 also landed by this version.
What used to be installed as plugins is now part of Amenbo itself. The changes from 24.3.0, 25.0.0 and 26.0.0 also landed by this version.
The plugins are part of Amenbo now
Notifications and worktrees no longer need a plugin found and installed. Nothing to install and nothing to enable. If you had them installed on an earlier version, your settings are carried over, and the first time you open this version the app says once what moved where.
- mail and Slack settings — the device’s notification targets, and which projects report through them
- the keys used for pairing
The plugins you had installed are removed during the migration. The plugin screens, and the Plugins section in the sidebar, are gone. There are no amenbo plugin commands.
A connection is written on the device once
Task activity can go to Slack or to mail. A connection is written once on the device, and projects choose from those. When a webhook changes, there is one place to edit.
| Where | What it decides |
|---|---|
| Settings › Notification targets | the connection itself (a Slack webhook, a mail account), given a name |
| Project settings › Notifications | on/off, which targets to send through, what it reports |
13 events can be reported: task created / done / assigned / moved, decision accepted and rejected, comment added, and so on. For dates, the day arriving and the day being tomorrow are each said once a day.
A connection can be tried where it was typed. “Check the connection” reads the shape of the settings, and for mail it goes as far as connecting to the server and offering the account. “Send a test message” actually sends one. Whether it can send is settled there, rather than by the first notification not arriving.
Notification text comes out in the language chosen in the app.
A task can be given a git checkout of its own
Two sessions on one working tree mix each other’s unsaved edits. A task can now be cut a checkout of its own.
eval "$(amenbo worktree start 123)"
Where it goes is fixed and nobody is asked: beside the repository, at <repository name>-worktrees/<task number>, on branch task/<task number>. It sits beside the project folder rather than inside it, so an AI running there cannot reach the real backlog.
The amenbo worktree finish 123 command takes the checkout and the branch away. It refuses while there are uncommitted changes, or commits that have not landed.
More on panes
- The box under a pane folds away — folded is the default, and this machine remembers whether it was open.
- Enter is a newline — sending is Enter with your OS’s own modifier, and the send button only takes colour when there is something to send.
- The bottom row names the model — a pane says which model it is talking to, and reopening the app puts it back on that model.
- Codex and Gemini panes come back to their previous conversation — each pane is its own conversation.
- On macOS, Option can be the meta key — for the keys inside a pane that want a meta.
Getting it
Open the installer for your OS from the latest release. No admin rights are needed.
- macOS —
.pkg, one for Apple silicon and one for Intel (GUI and CLI come together) - Windows — setup
.exe(GUI and CLI come together) - Linux — the GUI is an AppImage; the
amenbocommand comes from the CLI installer
To update: on the GUI, the “a newer version is available” banner applies it in place. If you installed only the CLI, amenbo update --apply swaps it.
The stored data format moves up — the first launch on this version migrates it, and a backup from before the migration is kept automatically. Once migrated, an earlier version can no longer open it. The GUI and the CLI are updated together by the same installer, so do not leave one of them on the old version.
New here? See Start.