romainsauvez

Hi Blasto,

Thanks for this positive, kind, and open-minded feedback!

I've taken note of all your recommendations!

Have a great day making music with Ableton!

Hi Syn,

Thanks for taking the time to compare and share thoughts — really useful feedback.

Quick context on what's possible

Multi-option menu / capability cards — totally doable and it's already on
our roadmap. ReaAssist's welcome screen with starter prompts maps cleanly
onto two features we're planning: a library of clickable prompt templates
organized by category (composition / mixing / organization / debug) that
copy to clipboard, plus a "what can I ask the agent?" cheat sheet for new
users. Should land in upcoming versions.

Automatic Gemini CLI login — we already do half of it: agent4live
auto-registers its endpoint in `~/.gemini/settings.json` so Gemini CLI sees
the device on first launch (same for Claude Code, Codex CLI, OpenCode).
What we can't do is authenticate Google for you — your API key stays in
your Google account. ReaAssist works around this by being a chat client
itself ("bring your own keys" inside their app), but agent4live is a tool
server: the LLM relationship is between you and whichever CLI you pair us
with. We can't legally or technically intercept that auth.

One architectural difference worth flagging — Reaper is famously open
and scriptable (Lua/JSFX), which is why ReaAssist can generate scripts and
have agents run them inline. Live is more closed: no equivalent scripting
layer for third-party agents. So instead, we expose **232 LOM tools** (Live
Object Model operations) for the agent to call individually. More granular,
does the whole task" pattern. That's a real ceiling we can't bypass unless
Ableton opens M4L further — which would be great but isn't on us.

I’ll keep pushing what's possible from inside a Max for Live device. Thanks again for the push.

Hi Conduct,

Glad to hear it's working well!

I'm trying to find solutions for the token issue, but it's not easy. Do you have any ideas?

On my end, I mostly use it with OpenCode and a local LLM to avoid token problems!

Hi Blasto,

Thanks for your feedback!

Unfortunately, the Ableton MCP you're referring to only exposes the knowledge base — it doesn't expose Ableton's API.

I'm sorry to hear the device isn't working for you. Could you explain the issue you're running into?

Security is very important to me and I'm trying to move forward on this topic as fast as I can! All sources are available on GitHub: https://github.com/romsau/agent4live

Here's what's already in place:

Loopback-only network surface — exclusive bind on 127.0.0.1 for HTTP MCP (app/server/index.js:365,484) and for the JSON-TCP bridge with the Python companion (app/server/python.js:15). Inaccessible from the network.

16-byte crypto-random Bearer — generated at boot, verified on every /mcp request, regex validation ^[a-f0-9]{32,}$ before adoption (app/server/config.js:60; app/server/mcp/server.js:54-64; app/server/discovery.js:47-58).

Token persisted across reboots — in ~/.agent4live-ableton-mcp/endpoint.json so CLI configs don't break on every relaunch (app/server/discovery.js:109-137).

Origin check on /mcp — blocks requests whose Origin header isn't 127.0.0.1 or localhost, explicit 403 with log (app/server/mcp/server.js:27-46).
chmod 0o600 on sensitive files — endpoint.json and preferences.json readable only by the user running Live, double-write mode + chmodSync (app/server/discovery.js:125-130; app/server/preferences.js:92-96).

Token never exposed via /ui/state — stripped by destructuring before JSON serialization (app/server/index.js:91). If the jweb is compromised, it cannot leak the Bearer.

Opt-in consent to modify CLI configs — the device never touches ~/.claude.json, ~/.codex/config.toml, ~/.gemini/settings.json, or ~/.config/opencode/opencode.json without explicit consent recorded in preferences.json (app/server/preferences.js:8-23; app/server/index.js:184-192).
Silent migration only for localhost entries — the first-boot scan rejects any non-loopback scheme via _isLocalhostUrl() (app/server/preferences.js:146-189,222-224).

Subprocess without command injection — execFileSync with args as an array (not exec with a string), no shell interpretation even if the token contained special characters. Strict timeout (app/server/discovery.js:179-186).

Isolated Python companion — communication only via loopback TCP socket in JSON-line format, no eval / no exec / no unsafe native Python deserializer, Python methods strictly validated on the companion side (app/server/python.js:25-77).

Tool input validation (Zod) — each tool defines a Zod schema, the MCP SDK validates args before calling the handler. No LOM injection via malformed tool args (app/server/tools/define.js:35).

Defensive code on external configs — all CLI config reads wrapped in try { } catch (_) {}, hand-rolled Codex TOML parser (zero TOML dependency added, no RCE risk from a buggy lib) (app/server/preferences.js:150-187).

Multi-device: only one active — EADDRINUSE → passive mode with no filesystem writes and no discovery, avoids overwriting the active instance's token (see docs/ARCHITECTURE.md section "Multi-device — passive mode").

I still have a few points left to handle, which will be delivered in version 1.3.

Good news! The device is now waiting for your agent to make a call. Once Ableton is open and you have dropped the device on a track, open Gemini CLI in your terminal and ask it to do something. Example prompt: "In my current Ableton project, change the tempo to 75 bpm."

Hello !

I've updated the device here, as well as on the website (https://agent4live-7cfed.web.app/) and on GitHub (https://github.com/romsau/agent4live). Hopefully this resolves your issues. Feel free to reach out to me on X as well: https://x.com/romainsauvez. Thanks for reporting these bugs to me.