The agent can now generate and edit images, and unattended runs get tighter controls

An agent that can do more is also an agent you have to fence in more carefully. This week Muse Code widens what the agent can produce - images, and Blender scenes rebuilt from reference pictures - and at the same time gives you sharper tools for unattended runs: an empty tool preset, a flag that stops questions, and permission profiles that are refused when they cannot be enforced.

Week 42 (October 13-16, 2026) brought four releases, 1.4.7 to 1.4.10, with 170 changelog entries. The items below are the ones that change how you start, run or administer sessions.

---

Image generation: what you need before the agent draws anything

The agent can now generate and edit images. This arrived in 1.4.7. The condition is in the changelog wording: your model catalog has to include an image model. Without one, nothing changes for you.

Check the catalog first. If you expected images and the agent does not produce any, the model catalog is the first place to look. The changelog entry mentions no other prerequisites, so that is all I can tell you for certain. I would not assume anything about formats, limits or plan availability until you have tried it on your own setup.

Why it matters for your workflow. Image editing sits in the same agent loop as your code and tools. That means the permission and tool controls described below apply to sessions that can now produce visual output as well. If you run unattended jobs, decide up front whether they should have this ability.

---

Changes for everyday work

/blender rebuilds reference images as Blender scenes. The new command, added in 1.4.10, reconstructs reference images as editable Blender scenes. The result is a scene you can edit, not a flat render. The changelog gives no further detail, so run it on a simple reference image before you hand it a complex one.

Terminals can show session status. If your terminal supports program status reports (OSC 7501), it can now show whether a session is working, waiting for you, or done (1.4.7). With several sessions open, a tab that says ‘waiting for you’ saves you from scanning each one.

--preset empty starts with no built-in tools. Added in 1.4.8. The model gets only the tools of the MCP servers you configured. That makes the tool surface of a run exactly as large as your MCP configuration.

--disable-request-user-input keeps unattended runs moving. Added in 1.4.9 for the TUI, muse exec and muse serve. It withholds request_user_input from the main conversation, so an unattended run never stops to wait on a question. Side chats keep the tool. If the model calls it anyway, it gets an unavailable-tool error. --yolo implies the flag on the TUI and muse exec.

Unenforceable permission profiles are now refused. The refusal announced in the earlier notes takes effect in 1.4.8. Before, a profile the live session could not enforce silently collapsed to read-only. Now it is refused when chosen at launch, either with --permission-profile or as the configured default. The message names each offending rule with a reason and a remedy: remove or adjust the rule, or set the temporary escape hatch to run with it unenforced and a warning.

What still works and what does not:

• Profiles that keep a built-in profile’s filesystem rules keep working, :unrestricted included.
• Profiles that add or change filesystem rules (deny rules included) are refused.
• Profiles that add workspace_roots are refused.
• Profiles that add Unix-socket rules are refused.

Most users can delete those rules and relaunch.

You can pick the profile on resume. The permissionProfile member of session/resume (and the SDK resume option) lets you choose the permission profile when resuming a served session. An id the host does not offer is refused before anything is written.

---

Technical notes

Session protocol and muse serve.

• On initialize, muse serve now tells session protocol apps whether the machine can enforce the shell sandbox and, if not, why (1.4.7).
• Apps connected to muse serve can follow a running subagent live by subscribing to its session (1.4.8).
• The session protocol now serves the model’s narration between tool calls as agentMessage items. Each completed one is marked as commentary or final answer through messagePhase (1.4.8).
• Clients receive an approval/reviewing view event while the built-in Auto-review reviewer holds an approval (1.4.9).

Approvals and Auto-review.

• Auto-review now hands an action to you once the reviewer has used 15 steps without reaching a decision (1.4.8).
• Plan files under .agents/plans/ no longer raise an approval card. The rest of .agents stays protected (1.4.8).
• sl and hg commands that use globs or braces, such as sl status *.rs, now ask for approval the way git commands do (1.4.8).

MCP. Every MCP tools/call carries the model’s tool-call id in _meta.callId, plus the idempotency key when one is set (1.4.9). Servers can use these to correlate calls and dedupe retries.

Context and background commands.

• Bash command results no longer repeat the command back to the model. A long inline script takes up context once instead of twice (1.4.8).
• A background command that runs past 30 minutes now prompts the agent once instead of every 30 minutes (1.4.10).

Skills and goals.

• A skill can set metadata.display-name in its SKILL.md. The transcript’s skill rows and the /skills list then show that name instead of the id (1.4.7).
• /goal <objective> now asks before replacing an unfinished goal. Esc keeps the current goal and your typed text (1.4.7).

---

What to take away

If you work in the terminal.

• Check whether your terminal supports OSC 7501 and whether the session status shows up.
• Try /blender on a simple reference image.
• If you use /goal, expect the new confirmation, and remember that Esc keeps both the current goal and your typed text.
• If the agent should draw, confirm that your model catalog contains an image model.

If you run parallel sessions.

• Use the status reports to see which sessions are working, waiting or done without opening each one.
• For unattended runs, add --disable-request-user-input (--yolo already implies it on the TUI and muse exec).
• Give runs that should touch nothing but MCP tools --preset empty.
• Remember that a background command past 30 minutes now prompts the agent once, not repeatedly.

If you administer integrations and company deployments.

• Audit your permission profiles before the update reaches your team. Any profile that adds or changes filesystem rules, adds workspace_roots or adds Unix-socket rules is now refused at launch. Remove the rules or use the temporary escape hatch while you sort it out.
• For apps built on the session protocol, look at the new permissionProfile member of session/resume, the approval/reviewing event, the agentMessage items with messagePhase, and the sandbox information in initialize.
• For MCP servers, use _meta.callId and the idempotency key to correlate calls and dedupe retries.

---

Sources: the Muse Code changelog, versions 1.4.7 to 1.4.10 (October 13-16, 2026), and the Muse Code documentation. Several entries give only a short description, so check behavior on your own setup before relying on it in production.