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.
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”