Right now it's all built in phaser, and furniture is pretty straight forward to build and deploy. But it requires modifying the source. We want to add support for easy drop in decoration in future updates.
The deny list for auto-approval is a pragmatic solution. In practice I've found the hard part isn't blocking obviously dangerous commands like rm -rf, it's the long tail of commands that are safe in one context but destructive in another (e.g. git checkout on a file with unstaged changes). Would be interested to know if you're tracking which auto-approved commands end up causing issues to refine the defaults over time.
The second level is called auto approve and is for more complex bash commands. Generally the model will ask permission before running one of these big commands, but you can allow all. Right now, it's global across the instance, but we're working on making it more granular.
Also, there is a deny list of certain commands which you can customize to prevent bad behavior (like rm -rf, etc...)
We want to wire the approval process to imessage or whatever channel, but we need to first auth the imessage session to make sure it's coming through from the owner and not someone else communicating through the same channel.
We're working on simultaneous editing of the same files using git, but we want to ensure changes are merged in an intelligent way.
I also hope it can have a webapp version, rather than electron. because most of our work are on a remote server.
It can use API/CLI or even if you have a private hosted instance.
We're actually working on a remote web app version but its a little trickier to wire up.
These are great questions - thank you!