El Yayster Inhabits Emacs to Run Gated Local LLM Agent Operations
El Yayster provides an Emacs agent running on local Ollama endpoints via a single-file implementation. It executes editor tasks using a gated ReAct loop, requiring manual user consent for mutating commands while keeping token credentials out of system process tables.

Impact: Medium
Why it matters
You can turn Emacs into an agentic coding environment using self-hosted local models without cloud dependencies or leaking API keys to process listings.
TL;DR
- 01Runs an autonomous agent loop locally using Ollama and an OpenAI-compatible endpoint.
- 02Enforces interactive confirmation prompts for any mutating elisp or shell execution.
- 03Prevents token leaks on shared machines by passing API keys through mode-0600 temporary files.
Key facts
- Default local endpoint
- http://localhost:11434/v1/chat/completions
- Default command timeout
- 30 seconds
- Key file permissions
- mode-0600
Embedded Execution Instead of Passive Chat
El Yayster operates as an embedded agent rather than a passive text completion interface. The package consists of a single elisp file (yayster.el) that relies strictly on built-ins (cl-lib, json, subr-x) and system curl. Every prompt provides the model with the active buffer list, current major mode, and working directory, enabling it to navigate and self-discover capabilities via apropos and describe.
ReAct Interaction and Safety Gates
Interaction follows a structured text-based ReAct protocol (ACTION:, ARGS:, FINAL:):
- Read-Only Auto-Approval: Inspections via
read_bufferandlist_buffersrun without interruption underyayster-auto-approve-readonly. - Interactive Mutating Gates: Actions involving
eval_elisp,write_buffer, orrun_commandprompt the developer with the exact command payload before execution. - Command Limits: The
run_commandcapability enforces a default 30-second timeout (yayster-command-timeout) and clamps terminal output size toyayster-command-max-bytes.
Process Security and Model Context Integration
When connecting to cloud or remote OpenAI-compatible hosts, API credentials written to yayster-api-key are delivered to curl via a temporary 0600 file (-H @FILE), ensuring keys never appear in system process listings (ps). An optional mode-line module (yayster-mode-line.el) monitors model responses, session token metrics, and active context-window consumption reported by Ollama.
Try it in 2 minutes
(add-to-list 'load-path "/path/to/yayster.el")
(global-set-key (kbd "C-c y") #'yayster-step)
(global-set-key (kbd "C-c Y") #'yayster-use-host)
(setq yayster-endpoint "http://localhost:11434/v1/chat/completions")elisp
✓ When to use
- Emacs developers seeking an offline-capable agent that can discover internal functions via apropos.
- Teams requiring strict audit confirmation before allowing an agent to execute mutating shell or elisp commands.
✕ When NOT to use
- Unattended automated pipelines where interactive gating prompts cannot be answered.
- Environments where users frequently execute untrusted buffers that might contain sensitive secrets.
What to do today
- Clone `yayster.el` into your load-path and bind `yayster-step` to `C-c y`.
- Pull a local instruction model with `ollama pull qwen3:8b` and verify `localhost:11434` connectivity.
- Review interactive permission prompts carefully before issuing Allow for mutating commands.
What the community says
“Most "LLM in Emacs" packages make Emacs a mouth that talks to a model... El Yayster inverts that. It makes Emacs a body the model inhabits — the agent perceives your live environment, and acts on it”
Sources