slash-agent
Type /agent in your shell and an LLM reads the terminal error and proposes commands you approve and run in place.
- Source repo
- akatzmann/slash-agent
- Stars
- ★ 10
- Last updated
- 8d ago
- License
- Apache-2.0
- Primary language
- Python
- FA score
- 47/100 · Major gaps
At a glance
- Works with
- Universal · cross-platformChatGPT · Claude Code · OpenAI API
- You'll need
- Typical use
- A developer whose build or test suite just failed types /agent Fix this and lets the agent read the traceback in the tmux scrollback and install the missing dependency.
- Main limitation
- Native Windows CMD/PowerShell is not supported; Windows users must run it inside WSL2.
- Source review
- 47/100 · Major gaps 1 safety controls not found
What does this agent do, and when should you use it?
slash-agent is a command-line LLM copilot that lives inside your active Bash, Zsh, Ksh or Fish session: a shell wrapper (bin/slash-agent.sh) registers an /agent command that hands off to a Python orchestrator (slash_agent/main.py). It scrapes the current tmux pane scrollback or shell history as context, then calls a local Ollama instance, OpenAI, Azure OpenAI, or any OpenAI-compatible endpoint such as llama.cpp or vLLM. Proposed commands run through a real pseudo-terminal behind a y/n/e/c confirmation loop, so you can see colored output, progress bars and answer sudo prompts interactively. On exit a temporary sourcing script pushes cd and export changes back into the parent shell. The tool is entirely on-demand with no daemon or idle memory use; native Windows is unsupported and WSL2 is required there.
Running /agent or agent triggers the shell wrapper, which captures context (up to AGENT_TMUX_LINES, default 50 lines of tmux scrollback, falling back to AGENT_HISTORY_COMMANDS, default 20 history entries) and invokes slash_agent/main.py. The orchestrator connects to an LLM using AGENT_BACKEND (ollama, openai, azure_openai, dummy) plus AGENT_ENDPOINT and AGENT_MODEL, with optional AGENT_THINKING_LEVEL, AGENT_TEMPERATURE and AGENT_TOP_P. Each returned command is shown as Confirm action: [y]es / [n]o / [e]dit / [c]omment before being executed in the PTY bridge; -n/--dry-run previews the plan, -y/--yes skips routine confirmations, and --unsafe-yes also auto-confirms critical commands such as rm -rf or sudo. After execution the exit code, PWD and environment updates are written to a sync file that the parent shell sources. It also discovers SKILL.md files from .agent/skills/, .claude/skills/, .github/skills/ and global skill directories.
- A developer whose build or test suite just failed types /agent Fix this and lets the agent read the traceback in the tmux scrollback and install the missing dependency.
- Someone setting up a local database, docker compose file or systemd service asks /agent for the commands and approves each one instead of looking up flags.
- An engineer in an offline or regulated environment points AGENT_BACKEND at local Ollama so terminal logs and source code never leave the machine.
- A user who wants directory and environment changes to persist in the main shell relies on the cd/export parent-shell sync instead of an isolated subshell.
- A cautious user previews the agent's plan with /agent -n before letting anything touch the system.
How do you install or deploy this agent?
Install with pipx and register shell integration:
pipx install slash-agent && slash-agent init --installOr with pip:
pip install slash-agent && slash-agent init --installThen restart the shell or reload it manually:
source ~/.bashrcIf you prefer not to use pipx, a self-contained curl installer is available:
curl -fsSL https://raw.githubusercontent.com/akatzmann/slash-agent/master/bin/installer.sh | bashFor development from source, clone the repo, install requirements and source the shell script:
pip install -r requirements.txt
source ~/.slash-agent/bin/slash-agent.shFish users source ~/.slash-agent/bin/slash-agent.fish; on macOS use ~/.bash_profile or ~/.zshrc. Windows users must install inside WSL2.
How do you use this agent?
Configure the backend, by default in ~/.config/slash-agent/env (override with SLASH_AGENT_CONFIG_FILE):
export AGENT_BACKEND="ollama"
export AGENT_MODEL="gemma4:latest"
export AGENT_ENDPOINT="http://127.0.0.1:11434"
export OPENAI_API_KEY=""
export AGENT_TMUX_LINES=50
export AGENT_HISTORY_COMMANDS=20
export AGENT_THINKING_LEVEL="off"Or run the interactive setup wizard, pre-filled with current values:
/agent --configureThen invoke it anywhere in the terminal:
/agent Fix this crash
/agent -n setup a docker compose file for PostgreSQL and Redis
/agent -y update package lists and install treeUpdate to a new release with:
/agent --updateWhat are this agent's strengths and limitations?
- Truly on-demand: no daemon, no keystroke listeners, 0MB idle memory, a sharp contrast with resident project agents.
- Reads the active tmux scrollback or shell history directly, removing the copy-paste step when diagnosing a crash.
- Executes in a real PTY so colored output, progress bars and interactive sudo password prompts work, while keeping a y/n/e/c steering loop and a dry-run mode.
- Syncs cd and export back to the parent shell via a temporary sourcing script, solving the subshell-can't-change-parent problem.
- Model agnostic with full local Ollama and OpenAI-compatible support, so terminal data can stay on-device; discovers SKILL.md files in Claude, Copilot and Gemini skill formats.
- Native Windows CMD/PowerShell is not supported; Windows users must run it inside WSL2.
- Commands execute against your live environment rather than a sandbox, and -y/--unsafe-yes bypasses confirmations, shifting blast-radius and cost risk to the user.
- Cloud backends require your own OpenAI/Azure keys and quota management; local use requires you to run Ollama or a compatible server.
- The README itself scopes it out of large repository architecture work and big refactors, limited by terminal-scrollback context.
- The README's MIT license badge conflicts with the repository's Apache-2.0 metadata, so license terms need verification before adoption.
- Default model names such as gemma4:latest must already be pulled locally, and troubleshooting across every backend is not fully documented.
How does this agent compare with similar options?
The README names three alternative classes directly: standard web UIs such as ChatGPT and Claude (manual copy-paste context, read-only, cloud only), shell copilots such as Copilot CLI or gh cli (print text for you to run, no parent-shell sync, cloud only), and project agents such as Aider or Claude Code (read the whole git repo, heavy idle runtimes, built for large autonomous feature work). It positions itself as an emergency lever after a crash rather than a replacement for deep coding sessions.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| slash-agent This agent | 47 · Major gaps | — | ★ 10 | 8d ago | Python | ChatGPT · Claude Code · OpenAI API |
| little-coder: Lightweight Local Coding Agent | 58 · Major gaps | CLIFree + model costs | ★ 2.7k | 1mo ago | TypeScript | — |
| Nanocoder | 50 · Major gaps | CLIFree + model costs | ★ 2.5k | today | TypeScript | OpenAI API · Claude API |
| GitHub Copilot CLI | 46 · Major gaps | CLIPaid | ★ 11k | today | Shell | ChatGPT · Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
The security model documents risk tiers, sensitive-path blocklists, 0o700/0o600 transient logs, and an interactive confirmation loop; user confirmation and data-flow transparency (BYOK, offline Ollama) are documented, so those score 2. least_privilege is only 1: tools execute arbitrary commands as the current user in a host PTY with no sandbox, and --unsafe-yes bypasses critical-command confirmation. dependency_security is 1: requirements.txt pulls the author's private py-agent-core via git+https tag with no hash pinning, weakening supply-chain traceability. external_effects is 1: commands mutate the real environment (cd/export synced to parent shell) with no rollback, so rollback is 0. source_attribution is 1: author is named but publisher identity is unverified.
self_consistency is 1: the README badge says MIT while LICENSE and pyproject say Apache-2.0, a direct contradiction; example model names (gemma4, gpt-6.1-sol) look like placeholders. dependency_availability is 1: the core dependency python-agent-core is referenced by git tag, so availability depends on an external repo. failure_messages is 1: tests show truncation notices and log-path echoes, but there is no systematic evidence of error-path messaging.
audience_and_scenarios is 2: clearly targets developers fixing terminal crashes with concrete use cases. capability_boundaries is 2: the IS/IS NOT table and Windows/WSL2 limits define boundaries. trigger_precision is 1: /agent triggering relies on shell-function injection and the -y/--unsafe-yes distinction requires user understanding; precision evidence is limited. environment_fit is 2: supports bash/zsh/fish/ksh and WSL2, with tests covering multi-shell init.
information_architecture is 2: README, docs/security_model, SECURITY.md, and docs/documentation are layered clearly. install_notes is 2: pipx/pip/curl and source installs are documented. naming_stability is 1: /agent and agent coexist and --update/--upgrade/-u are multiple aliases, with limited stability evidence. examples_and_faq is 2: multiple scenario examples and a comparison matrix. known_limitations is 2: explicitly not a sandbox, not an architecture tool, no native Windows. license is 2: full Apache-2.0 LICENSE present. versioning_changelog is 1: pyproject shows 0.2.1 and SECURITY has a supported-version table, but no CHANGELOG. maintenance_responsibility is 1: only points to @akatzmann with unverified publisher, so ownership is thin.
output_usability is 2: PTY interaction, edit/comment loop, and log collapsing improve usability. marginal_value is 2: terminal context capture and parent-shell state sync add value over generic chat. cost_benefit is 1: zero idle overhead is a selling point, but cloud token costs are user-managed with no evidence of built-in budget controls.
claim_traceability is 1: the security model and risk tiers are documented, but most safety claims do not point to specific code files. cross_source_corroboration is 1: README, security_model, and SECURITY.md echo each other, but tests cover only some tool functions and do not corroborate path blocklists or risk scanning. fact_inference_separation is 1: marketing claims (zero memory, 100% offline) are mixed with implementation detail without clearly separating assertion from verified fact.
- Not found in source: rollback or recovery pathBack up first, or work on a git branch or snapshot, so its changes can be undone.
- README badge says MIT while LICENSE and pyproject say Apache-2.0; the license claim is self-contradictory and must be confirmed before use.
- Tools execute arbitrary commands as the current user in a host PTY with no sandbox; --unsafe-yes bypasses critical-command confirmation, risking destructive actions with no rollback.
- The core dependency python-agent-core is pulled via git+https tag with no hash pinning, weakening supply-chain traceability.
- Publisher identity is unverified; maintenance responsibility and update path point to a single author.
- Example model names (gemma4, gpt-6.1-sol) look like placeholders; real availability must be verified independently.