A single request for a 3D page used to be able to start two competing build processes, and a deny rule in an :ask-me permission profile could be silently ignored. This week fixes both. The headline is a set of built-in skills for 3D pages and browser games that play what they build before handing it over. Alongside them come local port rules for sandboxed commands, filesystem deny rules that are now enforced, and a command to check your subscription allowance.
Week 43 (October 19-24, 2026) covers versions 1.4.11 to 1.4.13: 3 releases and 226 changelog entries. Most of the entries are small, so this post sticks to what changes how you work.
Skills that build 3D pages and games, then play them
Four skills share the work. web3d builds single-file 3D web pages and browser games and checks them in a browser before handoff. browser-game builds playable games from a brief. visual-coding is a router: for a 3D page, a browser game or Blender work, it points the agent to the one built-in skill that owns that kind of work before any code is written. /game-3d-visuals drives 3D models and games from reference images, a visual spec and a render-vs-reference acceptance loop.
Routing removes the double build. Before visual-coding (1.4.13), one request could run two competing build processes. Now a single skill takes it from the start. That is the practical gain here, and you do not have to pick the skill yourself.
web3d plans before it builds. It plans each part’s shape, surroundings and materials first. After the first working build, a fresh tester subagent plays the page and writes a critique. That critique must be closed before delivery, and review rounds have a time guard so the loop does not run indefinitely.
browser-game sizes the work to the request. It plays the game with real input before handoff. For a long design document it runs up to three rounds. In each round a fresh critic plays a copy of the game against a checklist and the brief’s rules, and the agent fixes what the round finds.
/game-3d-visuals got faster and quieter. It now finishes in about half the time, because it skips the separate visual-plan review and runs one render-vs-reference fix round by default. It also starts on its own only for polished 3D work:
- a reference image,
- Blender,
- or an explicit high-fidelity ask.
Quick 3D pages and games are built directly instead of waiting on its multi-agent pipeline. If you want the full pipeline for a quick page, ask for high fidelity explicitly.
/blender is wider too. It now handles general 3D work: modeling, scene recreation from an image, animation and large environments. It can measure a render against its reference and check animations frame by frame for pops, sinking and objects leaving the shot.
Changes for everyday work
Local dev ports for sandboxed commands. Permission profiles can now open chosen local development ports with network.local_ports, set to allow, ask or deny per port. With ask, Linux prompts for each connection and macOS prompts once per session. A loopback entry in network.targets is now rejected, so move it to network.local_ports. One compatibility catch: an older Muse build cannot open a chat that saved local-port rules or a managed local-port limit. Update the app to open it. Other chats are unaffected. Details are in the permissions documentation.
Deny rules in :ask-me profiles now count. On macOS and Linux, profiles extending :ask-me enforce filesystem deny rules instead of silently ignoring them. Workspace-root deny globs such as **/*.pem and absolute or ~/ denies refuse matching reads and writes. They also block sandboxed shell access to matching paths that exist when each command starts. The profile keeps its write grants elsewhere. Two edge cases:
- On Linux, files created mid-command under a deny glob are not covered. macOS enforces globs live through Seatbelt regex, with no snapshot window.
- A deny on a path that does not exist yet is masked at its first missing component.
If you wrote deny rules for an :ask-me profile and assumed they worked, they now do (see the permissions documentation).
Check your allowance with muse usage. The command shows your subscription allowance (window and weekly use, reset times, tier) without running a model turn. muse exec --json reads the same data when the run saw no usage update. See the subscriptions documentation.
Plugins can ship MCP servers. Agent plugins can now supply MCP servers. Each server gets its own review, and you sign in with muse mcp login. The extending documentation covers the details.
Session hand-off, answers and presets. The session protocol gains session/leave. A client can hand one loaded session to another host while the first host and its other sessions keep running. The TypeScript and Python SDKs can answer the agent’s questions with Session.answerUserInput and Session.answer_user_input, including a question still open when a session is resumed. muse serve --preset lets you choose a run preset when starting a session host. More in the session messaging documentation.
Technical notes
Approvals and network prompts
- Network approval prompts now default to ‘Yes, don’t ask again this session’ for that exact host and port, so pressing Enter stops repeat prompts (1.4.11).
- After you allow a network request once, later requests from the same non-interactive command to that exact host, port and protocol no longer ask again (1.4.12).
- Auto-review no longer hands you every request to
localhostor127.0.0.1just because of its address. It reviews them like any other action (1.4.11). - When a sandboxed command fails writing outside the writable roots, the error now explains that the sandbox blocked it. It names the
workspace_rootsgrant, a one-time unsandboxed run, and workspace-or-/tmpcache options (1.4.12).
Usage reporting
muse exec --jsonprints arun.usageline before each run ends, with token usage per model and your subscription allowance (1.4.11)./usagetotals now include background work, broken out in a separate Observers row (1.4.11).- Warnings near your usage limit show the remaining allowance and reset time above the message queue (1.4.13).
Models and clients
- Desktop and other connected clients now offer the same third-party models as the terminal model picker (1.4.13).
SDKs and non-interactive runs
- The TypeScript and Python SDKs accept an approval handler and an approval-failure observer when resuming a session, so an approval pending at resume reaches the handler (1.4.11).
--yolonow keeps therequest_user_inputquestion tool and enables async questions. Pass--disable-request-user-inputfor runs that should ask nothing (1.4.13).
Agent behavior
- Tiny text, style or config changes, throwaway prototypes and quick-result requests no longer start by writing a failing test. Other fixes run the broad test suite once after the last edit and post a status line during long runs (1.4.12).
What to take away
If you work in the terminal:
- Ask for a 3D page or small browser game and watch whether the agent plays it before handoff. For a quick page you do not need to name a skill.
- Say ‘high fidelity’ or attach a reference image when you want the
/game-3d-visualsloop. - Run
muse usageto see where you stand against your allowance. - Check your
--yoloscripts: the question tool now stays on, so add--disable-request-user-inputto runs that must ask nothing.
If you run parallel sessions or build on the SDKs:
- Try
session/leaveto hand a loaded session to another host. - Try
muse serve --presetto start a host with a chosen run preset. - Wire
Session.answerUserInputorSession.answer_user_inputinto your client, and pass an approval handler on resume so a pending approval does not get lost.
If you administer integrations or company deployments:
- Review
:ask-meprofiles that carry filesystemdenyrules. They are now enforced on macOS and Linux, so check that nothing you rely on is blocked. - Move any loopback entry from
network.targetstonetwork.local_ports, because it is now rejected. - Update older Muse builds before they meet a chat that saved local-port rules or a managed local-port limit.
- If you distribute agent plugins, note that they can now ship MCP servers. Each server gets its own review, and users sign in with
muse mcp login.
Sources: the Muse Code changelog, versions 1.4.11 to 1.4.13 (October 19-24, 2026), and the Muse Code documentation pages linked above. The built-in skills have no dedicated documentation page, so their behavior here comes from the changelog entries alone.
