Related Pages

Related topics: Agent System, Tools, Skills & Hooks, LLM Providers, MCP, LSP & Catwalk

Overview, Installation & Configuration

Project Overview & Purpose

Crush is a terminal-based coding assistant ("your new coding bestie") that wires user tools, code, and workflows into an LLM of choice. It is built by Charm and lives alongside companion projects such as Catwalk, which supplies Crush-compatible model metadata. Source: README.md.

The application is composed of layered, transport-agnostic modules:

• internal/app defines the top-level App container that owns session, message, history, permission, file-tracking, agent coordinator, LSP, and skills services (AgentCoordinator, LSPManager, Skills, `Sess

Related Pages

Related topics: Overview, Installation & Configuration, LLM Providers, MCP, LSP & Catwalk

Agent System, Tools, Skills & Hooks

Overview

Crush is a terminal-based AI coding assistant whose core engine is a per-workspace agent coordinator that drives a model through a turn loop, executes tools, applies skill instructions, and publishes a stream of events to clients (TUI, HTTP/SSE, or ACP). The agent system sits inside an app.App (internal/app/app.go), which owns the AgentCoordinator, the Skills manager, the LSPManager, and the runCompletions broker that signals "this run is fully done" to downstream consumers.

The agent surface is exposed in three layers:

1. Internal agent loop — internal/agent holds the Coordinator interface, the per-session agent runner, and the AcceptedRun lifecycle handle.
2. Transport-agnostic backend — internal/backend wraps the coordinator behind SendMessage, Cancel, and workspace bookkeeping.
3. Protocol adapters — HTTP/SSE in internal/server and ACP for IDEs forward events to subscribers.

Agent Lifecycle and Run Semantics

The agent.Coordinator interface (internal/backend/agent_test.go:18-41) exposes both a synchronous Run and an asynchronous RunAccepted plus the session bookkeeping methods (BeginAccepted, Cancel, CancelAll, IsBusy, IsSessionBusy). The AcceptedRun handle is the per-turn "lease" returned by BeginAccepted; until RunAccepted actually consumes it, the run is in an *accepted-but-not-yet-active* window that can be deterministically cancelled (internal/backend/accepted_run_integration_test.go:21-42).

sequenceDiagram
  participant Client
  participant Backend
  participant Coordinator
  participant Agent
  Client->>Backend: SendMessage(workspaceID, AgentMessage{RunID, Prompt})
  Backend->>Coordinator: BeginAccepted(sessionID)
  Coordinator-->>Backend: AcceptedRun handle
  Backend->>Coordinator: RunAccepted(ctx, accept, sessionID, prompt)
  Coordinator->>Agent: dispatch turn loop
  Agent-->>Client: streaming events (tool calls, messages)
  Agent->>Coordinator: terminal result
  Coordinator-->>Backend: publish RunComplete(RunID)
  Backend-->>Client: release RunCompletions for RunID

A failure-mode worth knowing: if RunAccepted returns an error *before* the coordinator publishes its own terminal RunComplete (for example, an early UpdateModels or readyWg failure), the backend emits a fallback terminal RunComplete keyed by RunID so callers blocked on that signal cannot hang (internal/backend/agent_runcomplete_test.go:30-58). The agent.MarkRunCompletePublished(ctx) helper lets a real coordinator tell the backend "I already published it, don't double-publish" (internal/backend/agent_runcomplete_test.go:21-26).

Backend error sentinels that callers must handle are declared once in internal/backend/backend.go:27-37: ErrWorkspaceNotFound, ErrAgentNotInitialized, ErrEmptyPrompt, ErrClientNotAttached, and ErrWorkspaceClosing. The agent also returns its own agent.ErrEmptyPrompt (internal/backend/agent_test.go:51-55).

Tools and the Per-Workspace Wiring

Tools in Crush are not configured globally; they belong to the App instance attached to a backend.Workspace (internal/app/app.go:54-79). Every workspace carries its own AgentCoordinator, Skills, LSPManager, and event broker, so tools can react to per-project context (file tracker, LSP diagnostics, permissions, skills).

The transport layer reports liveness via isSessionBusy(ws, sessionID) (internal/server/events.go) and counts "real" viewers with attachedClients(ws, sessionID), which excludes hold-only clients (streams == 0). This distinction is what lets the backend safely tear down a workspace whose SSE streams have gone idle without racing the next reconnect.

A community-reported gap: the agent tool itself has been observed to return no output, wasting tokens and forcing the parent LLM to redo work (issue #3118, #3117). Likewise, file tools are reported not to honor .crushignore (#3116) — if you depend on ignore-file filtering, configure it via .gitignore until that gap is closed.

Skills System

Skills are Markdown files (SKILL.md) discovered from a list of directories. The README documents three frontmatter flags (README.md):

Skill paths are configured via options.skills_paths (project-relative or absolute). Skills from project directories are namespaced project:, skills from global dirs are user:. The bundled crush-config skill lets you ask Crush to reconfigure itself.

The server publishes skill liveness via proto.SkillsEvent, which carries a []*skills.SkillState payload with Name, Path, State (e.g. StateNormal, StateError), and an optional Err (e.g. broken frontmatter) (internal/server/events_test.go). Round-tripping the event through the SSE envelope is part of the test suite, so clients can rely on State updates arriving intact.

Two known sharp edges worth pinning in your config (#2938, #2991):

• Recursive scanning of skills_paths does not skip hidden directories (those starting with .) — vendor folders or multi-agent embeds can leak unwanted skills.
• SKILL.md files nested deep inside skill directories are still discovered; if you ship a skill whose tree contains its own subskills, they'll all be loaded.

Hooks, Attribution, and Related Knobs

Crush does not expose a generic pre/post-tool hook API in the sense of arbitrary user scripts; instead it exposes deterministic configuration that effectively hooks into commit and PR creation:

• options.attribution.trailer_style — assisted-by (default), co-authored-by, or none (README.md).
• options.attribution.generated_with — adds 💘 Generated with Crush to commits/PRs when true.
• options.initialize_as — filename (default AGENTS.md) used when Crush bootstraps project context for future sessions.
• CRUSH_GLOBAL_CONFIG / CRUSH_GLOBAL_DATA — environment overrides for config and ephemeral data locations.
• providers.<id> — custom OpenAI-compatible (openai-compat) or Anthropic-compatible endpoints, including model pricing (cost_per_1m_in, cost_per_1m_out, cost_per_1m_in_cached) used by the cost tracker (README.md, internal/client/config.go).

Permissions UX is also part of the tool surface: release v0.76.0 added a 350 ms input-ignore window after the permission dialog appears to prevent accidental accept/deny from stale key events.

See Also

• Server, HTTP API & SSE Events
• Workspaces, Sessions & Storage
• Providers, Models & Authentication
• Configuration Reference

Related Pages

Related topics: Overview, Installation & Configuration, Agent System, Tools, Skills & Hooks

LLM Providers, MCP, LSP & Catwalk

Crush is a terminal-based AI coding assistant whose three most consequential extension surfaces are its LLM provider integration, its Model Context Protocol (MCP) plug-in system, and its Language Server Protocol (LSP) awareness. A fourth piece, Catwalk, supplies the canonical catalog of providers and models that all three surfaces draw from. This page documents how those four subsystems are wired together inside the codebase and how a technical user can reason about their configuration, runtime behavior, and known failure modes.

LLM Providers and Catwalk

Crush is intentionally model-agnostic. The README advertises "Multi-Model" support, the ability to switch LLMs mid-session, and the ability to register custom OpenAI- or Anthropic-compatible APIs. Source: README.md.

Catwalk is the open-source provider database that Crush uses as its source of truth for available providers, models, and per-model cost metadata. By default, Crush automatically fetches the latest Catwalk catalog so that new providers appear without a Crush release. This auto-update can be disabled in two equivalent ways: by setting "disable_provider_auto_update": true in options, or by exporting CRUSH_DISABLE_PROVIDER_AUTO_UPDATE=1. Manual refresh is exposed through crush update-providers, which accepts a remote URL or a local JSON file path, and a fallback command resets providers to the version embedded at build time. Source: README.md.

For custom integrations, Crush supports two OpenAI flavors. The README is explicit that "openai" should be used when proxying or routing through OpenAI itself, while "openai-compat" is the correct choice for non-OpenAI providers that expose an OpenAI-shaped API (e.g., Deepseek, OpenRouter-compatible endpoints). Each model entry carries cost_per_1m_in, cost_per_1m_out, and cost_per_1m_in_cached fields so Crush can report accurate per-session spend. Source: README.md.

Configuration files are resolved in priority order .crush.json → crush.json → $HOME/.config/crush/crush.json, and ephemeral state lives in $HOME/.local/share/crush/crush.json (or %LOCALAPPDATA%\crush\crush.json on Windows). Two environment variables, CRUSH_GLOBAL_CONFIG and CRUSH_GLOBAL_DATA, let advanced users relocate both directories. Source: README.md.

MCP (Model Context Protocol)

MCP is Crush's plug-in layer for adding tools, prompts, and resources without recompiling. The README documents support for three transports: http, stdio, and sse. Source: README.md.

At runtime, MCP state is tracked per workspace. The backend package exposes GetMCPPrompt, which resolves a workspace from its ID and delegates to commands.GetMCPPrompt using the workspace's resolved configuration. Source: internal/backend/config.go. The transport-agnostic backend layer is documented in internal/backend/backend.go, which exposes common error sentinels (ErrWorkspaceNotFound, ErrInvalidClientID, ErrClientNotAttached, ErrWorkspaceClosing) and constants like DefaultCreateGrace that govern how long a client has to open an SSE stream after workspace creation.

On the wire, MCP state and events flow through the same event envelope as LSP and permission events. The server-side switch in internal/server/events.go maps pubsub.Event[mcp.Event] into the protobuf representation, surfacing Type, Name, State, Error, and ToolCount to subscribers. Source: internal/server/events.go. The HTTP layer in internal/server/config.go exposes GET /workspaces/{id}/mcp/states and POST /workspaces/{id}/mcp/refresh-prompts; the latter requires a JSON body identifying the MCP server by name. The client wrapper that calls these endpoints lives in internal/client/config.go, which also implements GetMCPPrompt and an MCP resource reader that returns decoded MCPResourceContents.

LSP (Language Server Protocol)

Crush starts LSPs the same way a human developer would — for additional context to inform decisions — and treats them as first-class runtime objects. The internal/app/lsp_events.go file defines the event vocabulary: LSPEventStateChanged and LSPEventDiagnosticsChanged, plus an LSPClientInfo struct that carries Name, State, Error, Client, DiagnosticCount, and ConnectedAt. A process-wide lspStates map and a lspBroker pub/sub broker fan events out to any subscriber. Source: internal/app/lsp_events.go.

Subscribers obtain a per-context channel via SubscribeLSPEvents(ctx), and snapshot the entire state table with GetLSPStates(). Diagnostics counts and state changes are forwarded over the same SSE envelope used for MCP and permission events, with LSPEvent mapped onto proto.LSPEvent in internal/server/events.go. Debug visibility can be toggled with "debug_lsp": true in the options block. Source: README.md.

How the Surfaces Compose

flowchart LR
    User[User / CLI] --> Catwalk
    Catwalk -- "auto-update catalog" --> Providers[LLM Providers]
    Providers --> Agent[Crush Agent Loop]
    Agent --> LSP[LSP Clients]
    Agent --> MCP[MCP Servers]
    LSP -- "diagnostics, state" --> Events[Event Broker]
    MCP -- "tools, prompts, resources" --> Events
    Agent -- "permission requests" --> Events
    Events --> SSE[SSE / Proto Stream]

The diagram shows how a single prompt crosses all four surfaces: Catwalk provides the model definition, the provider serves the completion, the agent loop calls MCP and LSP for ground truth, and every state change is republished through one event broker that both the local TUI and remote HTTP clients can consume.

Known Limitations and Community Pain Points

Several open issues highlight real-world friction in the integration points described above. The "Agent tool sometimes fails to return any output" reports (#3118, #3117) trace intermittent empty outputs through the agent loop. Users hitting the context-window ceiling despite configuring context_window (#824) are seeing a provider/agent boundary problem rather than an LSP or MCP issue. Cache-hit regressions on Hyper-routed models (#3110) are a provider-side concern, not a Crush bug. Finally, deep discovery of SKILL.md files inside skills directories (#2938, #2991) affects which MCP-adjacent capabilities get auto-loaded and is worth checking before debugging missing tools.

See Also

• Backend Architecture
• HTTP Server & Proto API
• Skills System
• Catwalk (provider catalog)

Related Pages

Related topics: Overview, Installation & Configuration, Agent System, Tools, Skills & Hooks

TUI, Workspaces, Persistence & Operations

This page documents the runtime surfaces that the Charm Crush terminal client and its headless server expose: the workspace lifecycle managed by the transport-agnostic backend package, the persistence model (config files, data directories, and database-backed services), the operations endpoints used for control and configuration, and the events/UI plumbing that drives the TUI.

1. Backend and Workspace Lifecycle

The backend package is the heart of Crush's multi-workspace model. As stated in its package comment, it "provides transport-agnostic operations for managing workspaces, sessions, agents, permissions, and events. It is consumed by protocol-specific layers such as HTTP (server) and ACP." Source: internal/backend/backend.go:9-11

A Backend is constructed with New(ctx, cfg, shutdownFn) and owns two parallel indices: a csync.Map[string, *Workspace] keyed by workspace ID, and a pathIndex map for fast deduplication by resolved filesystem path. Source: internal/backend/backend.go:21-32

CreateWorkspace enforces "first-wins semantics": if a workspace already exists at the same resolved path, the existing one is returned rather than spawning a duplicate. The caller must supply a valid UUID ClientID; the resulting workspace registers a creation hold on behalf of that client, which is released either by the first SSE attach (converted into a stream claim) or by the DefaultCreateGrace window. Source: internal/backend/backend.go:42-50

Path keys are canonicalized through resolveWorkspaceKey, which applies filepath.Abs and then attempts filepath.EvalSymlinks, falling back to the cleaned absolute path on error. The dedicated test confirms both the symlink-resolving and the non-existent-fallback branches. Source: internal/backend/backend.go:177-187, internal/backend/backend_test.go

Client IDs are validated by validateClientID, which rejects empty strings and non-UUID values with ErrInvalidClientID. Source: internal/backend/backend_test.go

Hold and shutdown semantics

Workspaces are torn down by holds expiring. The test TestHoldExpiry_TearsDown proves that a registered client whose hold expires triggers both the per-workspace shutdownFn and the server-level shutdownFn in the same goroutine order they were registered. Source: internal/backend/backend_test.go

releaseHold is idempotent: calling it twice on the same (workspace, client) pair does not double-invoke the shutdown closure (TestReleaseHold_NoStreams). However, when a client has an active stream, releasing the hold keeps the workspace alive for the duration of the attachment (TestReleaseHold_WithActiveStream). Source: internal/backend/backend_test.go

2. Agent Run Coordination and Cancellation

Each workspace owns a single agent.Coordinator exposed through app.App.AgentCoordinator. Backend.SendMessage validates the workspace, then delegates to the coordinator; a nil coordinator surfaces ErrAgentNotInitialized, and an empty prompt surfaces agent.ErrEmptyPrompt. Source: internal/backend/agent_test.go

The run-completion pipeline is a first-class contract. App.runCompletions is described as "the authoritative per-run completion signal, emitted once per top-level agent turn after all message updates have been flushed," and is bridged into the app-wide events pubsub broker so SSE subscribers (notably crush run) can synchronize. Source: internal/app/app.go

When a run fails before the coordinator can publish its own terminal event — e.g. a readyWg or UpdateModels failure — Backend.RunAgent is required to publish a terminal RunComplete for the run's RunID. Without it, a crush run caller blocking on that RunID would hang because TypeAgentError is not a guaranteed terminal signal. The regression test TestRunAgent_PreRunErrorPublishesTerminalRunComplete enforces this. Source: internal/backend/agent_runcomplete_test.go

On the HTTP side, POST /v1/workspaces/{id}/agent is intentionally fire-and-forget: TestPostAgent_ReturnsOKOnContextCanceled shows that if another client cancels the session mid-turn, the prompting POST returns 200 immediately and the cancellation surfaces through the assistant message with the FinishReasonCanceled marker, never as a 500. Source: internal/server/agent_cancel_test.go

3. Persistence: Config, Data, and Application State

Crush separates *configuration* from *ephemeral state*, and Crush supports layered config files with a documented priority order. The README states: "Configuration can be added either local to the project itself, or globally, with the following priority: 1. .crush.json 2. crush.json 3. $HOME/.config/crush/crush.json." Source: README.md

Ephemeral state lives in a separate data directory:

Source: README.md

Both locations can be overridden through the CRUSH_GLOBAL_CONFIG and CRUSH_GLOBAL_DATA environment variables. Source: README.md

The App struct holds long-lived services that read and write through this persistent state: Sessions, Messages, History, Permissions, FileTracker, and the Skills manager. Each is a *Service interface* and is created and torn down via app.cleanupFuncs, which the test helper ShutdownForTest exercises (running every cleanup with a background context) since the full production path goes through App.Shutdown and releases the database, LSP, and MCP subsystems. Source: internal/app/app.go, internal/app/testing.go

Community note. Users have reported that "Crush tools does not respect .crushignore" (see issue #3116). The README advertises respect for .gitignore and a .crushignore override, so the persistence-side intent is clear even if the tool-side enforcement is incomplete in the current build.

4. Operations: Server Control, Config, and Events

The controllerV1 registered in internal/server/proto.go exposes the operations surface. Notable endpoints include:

• POST /control — accepts a proto.ServerControl whose only current command is "shutdown", which calls Backend.Shutdown(). Unknown commands yield a 400. Source: internal/server/proto.go
• GET /config — returns the full *config.ConfigStore as JSON. Source: internal/server/proto.go
• GET /workspaces — lists all running workspaces through Backend.ListWorkspaces(). Source: internal/server/proto.go, internal/backend/backend.go:60-66

Config is also writable at runtime: POST /workspaces/{id}/config/set decodes a proto.ConfigSetRequest and delegates to Backend.SetConfigField(scope, key, value); a symmetric …/config/remove endpoint exists for deletes. Both return 400 on bad JSON, 404 if the workspace is unknown, and 500 for unexpected backend errors. Source: internal/server/config.go

The client side mirrors these endpoints. Client.CreateWorkspace posts to /workspaces after stamping its own clientID; GetWorkspace does a typed GET and decodes the response into proto.Workspace. Source: internal/client/proto.go

The events package glues the agent coordinator to the TUI. isSessionBusy reports whether a workspace has an in-flight run for a given session, tolerating a nil workspace so REST handlers can pass GetWorkspace's result through unconditionally. Similarly, attachedClients returns the number of *viewing* clients (i.e. those with streams > 0) for a session, used to drive per-session presence in the UI. Source: internal/server/events.go

Community note. A long-standing request for a crush run --last-message flag (issue #2265) targets exactly this layer: headless callers want to consume the same runCompletions-backed stream and print only the terminal assistant message, which is now a supported pattern because runCompletions is a first-class signal rather than an inferred one. The context-limit problem reported in #824 lives one layer up, in provider/model selection, and is out of scope for the workspace operations described here.

See Also

• Configuration & Providers
• Backend API reference
• Server control plane
• Client protocol
• Skills system

Doramagic Pitfall Log

Found 29 structured pitfall item(s), including 3 high/blocking item(s). Top priority: Security or permission risk - Security or permission risk requires verification.

1. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/charmbracelet/crush/issues/824

2. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/charmbracelet/crush/issues/3110

3. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/charmbracelet/crush/issues/2938

4. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: Context limit not respected in requests
• User impact: Developers may misconfigure credentials, environment, or host setup: Context limit not respected in requests
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: Context limit not respected in requests. Context: Observed when using macos
• Evidence: failure_mode_cluster:github_issue | https://github.com/charmbracelet/crush/issues/824

5. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: Crush tools does not respect .crushignore.
• User impact: Developers may misconfigure credentials, environment, or host setup: Crush tools does not respect .crushignore.
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: Crush tools does not respect .crushignore.. Context: Observed when using python, linux
• Evidence: failure_mode_cluster:github_issue | https://github.com/charmbracelet/crush/issues/3116

6. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: Vim Mode
• User impact: Developers may misconfigure credentials, environment, or host setup: Vim Mode
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: Vim Mode. Context: Source discussion did not expose a precise runtime context.
• Evidence: failure_mode_cluster:github_issue | https://github.com/charmbracelet/crush/issues/1199

7. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: feat: skip hidden directories during recursive skill scanning
• User impact: Developers may misconfigure credentials, environment, or host setup: feat: skip hidden directories during recursive skill scanning
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: feat: skip hidden directories during recursive skill scanning. Context: Source discussion did not expose a precise runtime context.
• Evidence: failure_mode_cluster:github_issue | https://github.com/charmbracelet/crush/issues/2938

8. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: v0.70.0
• User impact: Upgrade or migration may change expected behavior: v0.70.0
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: v0.70.0. Context: Source discussion did not expose a precise runtime context.
• Evidence: failure_mode_cluster:github_release | https://github.com/charmbracelet/crush/releases/tag/v0.70.0

9. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: v0.71.0
• User impact: Upgrade or migration may change expected behavior: v0.71.0
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: v0.71.0. Context: Observed when using python
• Evidence: failure_mode_cluster:github_release | https://github.com/charmbracelet/crush/releases/tag/v0.71.0

10. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: v0.74.0
• User impact: Upgrade or migration may change expected behavior: v0.74.0
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: v0.74.0. Context: Observed when using windows
• Evidence: failure_mode_cluster:github_release | https://github.com/charmbracelet/crush/releases/tag/v0.74.0

11. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: v0.75.0
• User impact: Upgrade or migration may change expected behavior: v0.75.0
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: v0.75.0. Context: Observed during version upgrade or migration.
• Evidence: failure_mode_cluster:github_release | https://github.com/charmbracelet/crush/releases/tag/v0.75.0

12. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: v0.76.0
• User impact: Upgrade or migration may change expected behavior: v0.76.0
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: v0.76.0. Context: Source discussion did not expose a precise runtime context.
• Evidence: failure_mode_cluster:github_release | https://github.com/charmbracelet/crush/releases/tag/v0.76.0

Community Discussion Evidence

Doramagic exposes project-level community discussion separately from official documentation. Review these links before using crush with real data or production workflows.

• Agent tool sometimes fails to return any output - github / github_issue
• Agent tool sometimes fails to return any output - github / github_issue
• Crush tools does not respect .crushignore. - github / github_issue
• [[HYPER] all inputs have 0% cache hit](https://github.com/charmbracelet/crush/issues/3110) - github / github_issue
• Vim Mode - github / github_issue
• Context limit not respected in requests - github / github_issue
• Flag to output final message only (headless mode) - github / github_issue
• feat: skip hidden directories during recursive skill scanning - github / github_issue
• Prevent Crush from finding skills deeply nested in skills directories - github / github_issue
• nightly - github / github_release
• v0.76.0 - github / github_release
• Configuration risk requires verification - GitHub / issue