TL;DR
floo's Muse connector now uses floo's HTTP API instead of the floo CLI.
- Muse's sandbox could not reach the CLI's update URL, so an installed binary could drift behind the docs and agents would hit confusing errors.
- CLI login writes a token to a config file. Muse already has a secret store, so the connector reads a floo API key from there.
- Getting the key is still manual: sign up, set up payment, copy the key, and save it in Muse.
We built floo around our CLI first. Our coding agents already used it, so it seemed like a straightforward choice: install the binary, run floo auth login, and let the agent work.
Then we tried it inside Muse's sandbox. The CLI couldn't reach its update URL, and our login flow left credentials in a config file in an environment we didn't control. Those two problems led us to move the connector to our HTTP API.
Keeping the CLI up to date
The first issue was keeping the CLI up to date. Inside Muse, the sandbox couldn't reach our update URL. The installed binary stayed where it was while the docs moved on. An agent could end up following instructions for commands, flags, or config keys its version didn't support. Without knowing it was out of date, it would get confusing errors and start trying to work around them.
We considered pinning versions, mirroring releases somewhere the sandbox could reach, or asking for our update domain to be allowlisted. Each was a possible fix, but each added work to make our distribution process fit someone else's environment.
Using HTTP removed the client binary from that process. We still have to keep the API and its documentation compatible, but the connector no longer depends on installing and updating a CLI inside the sandbox.
Credentials
Credentials were the other problem. floo auth login writes a token to a config file. That's familiar behavior for a developer tool, but Muse has its own secrets store and the config file is a different pattern.
Muse already has a secret store for credentials, so we used it. The user saves their floo API key there, and the connector reads it to authenticate requests. To rotate the key, they create a new one in floo settings and replace the stored value.
That also meant we no longer needed a separate CLI login flow for the Muse connector.
What is still manual
Getting that key remains a manual step. Today, you sign up for floo, set up payment, copy your API key, and save it in Muse's secret store.
We want an agent to be able to handle that setup itself: create an account, set up billing, and get a key in one flow. We're working on it, but it isn't seamless yet. For now, we've kept the manual setup rather than making users depend on an automated flow that is inconsistent.
Getting started
If you use an agent, install floo from getfloo.com/agents.md and tell it what to build.
Originally published on X.
Frequently asked questions
Why doesn't floo's Muse connector use the floo CLI?
Inside Muse's sandbox the CLI could not reach its update URL, so an installed binary could fall behind the docs. floo auth login also writes a token to a config file in an environment floo does not control. The connector uses floo's HTTP API instead.
How does the Muse connector authenticate to floo?
With a floo API key saved in Muse's secret store. The connector reads the key to authenticate requests. To rotate it, create a new key in floo settings and replace the stored value.
Can an agent set up a floo account on its own?
Not yet. Today you sign up for floo, set up payment, copy your API key, and save it in Muse's secret store. floo is working on a single flow where an agent creates the account, sets up billing, and gets a key.