The less obvious part: generated JS is being allowed to request subagents. In a real agentic runtime, `spawn_agent` should be a privileged system call, not a function the artifact inherits because the orchestrator happens to sit on Claude Code.
Right now the artifact and the host share the same permission surface. The generated code can ask for more compute, more context, more agents, and there is no kernel to attribute the request, refuse it, or kill the child. Headless Claude distracts from the real issue: a missing control plane.
The agent and the runtime need to be separate. If the runtime is the agent, that distinction collapses.
Done this exact thing. Fed an agent my actual keybindings and `M-x` history, let it regenerate a lean init.el. Two notes from the other side of it. It's great at the 2% you named, but it silently drops the muscle-memory stuff you never think about: which-key, the half-configured LSP, that one hydra. Diff the old and new against a day of real editing, not against your memory of what you use.
The bigger thing. "Ask the agent to build it" is fine here because init.el is read-only damage. Worst case it writes a file you `git diff` before trusting. That's the safe end of the spectrum. The instinct breaks the moment the same agent is touching things you can't cheaply inspect: package installs, shell-outs in a hook, anything with a side effect off your disk.
The lesson I keep relearning building this stuff: an audit log after the fact tells you what broke, it doesn't stop it. What you actually want is a capability check before the agent acts. This run is allowed to write `~/.config`, not to curl-pipe-sh. Plus a trail you can't quietly rewrite later, a hash chain, not a log file anyone with write access can edit. For an init.el that's overkill. For an agent you'd let near `apt` or your dotfiles repo, it's the whole game.