원클릭으로
shell-builtins
// Use when creating a new shell builtin command for Crush (internal/shell/), editing an existing one, or when the user needs to understand how commands are intercepted in Crush's embedded shell.
// Use when creating a new shell builtin command for Crush (internal/shell/), editing an existing one, or when the user needs to understand how commands are intercepted in Crush's embedded shell.
Use when the user needs help configuring Crush — working with crush.json, setting up providers, configuring LSPs, adding MCP servers, managing skills or permissions, or changing Crush behavior.
Use when creating a new builtin skill for Crush, editing an existing builtin skill (internal/skills/builtin/), or when the user needs to understand how the embedded skill system works.
Use when the user wants to add, write, debug, or configure a Crush hook — gating or blocking tool calls, approving or rewriting tool input before execution, injecting context into tool results, or troubleshooting hook behavior in crush.json.
Use when the user needs to query, filter, reshape, extract, create, or construct JSON data — including API responses, config files, log output, or any structured data — or when helping the user write or debug JSON transformations.
| name | shell-builtins |
| description | Use when creating a new shell builtin command for Crush (internal/shell/), editing an existing one, or when the user needs to understand how commands are intercepted in Crush's embedded shell. |
Crush's shell (internal/shell/) uses mvdan.cc/sh/v3 for POSIX shell
emulation. Commands can be intercepted before they reach the OS by adding
builtins — functions handled in-process.
Builtins live in builtinHandler() in internal/shell/run.go. This is an
interp.ExecHandlerFunc middleware registered in standardHandlers()
before the block handler, so builtins run even for commands that would
otherwise be blocked. The same handler chain is shared by the stateful
Shell type and the stateless Run entrypoint used by the hook runner,
so builtins are available identically in the bash tool and in hooks.
The handler is a switch on args[0]. Each case either handles the command
inline or delegates to a helper function.
builtinHandler() in run.go.os.Stdin/os.Stdout.
This ensures the builtin works with pipes and redirections:
case "mycommand":
hc := interp.HandlerCtx(ctx)
return handleMyCommand(ctx, args, hc.Stdin, hc.Stdout, hc.Stderr)
internal/shell/mycommand.go). The function signature must accept a
context.Context as the first parameter, plus args, stdin, stdout, and
stderr:
func handleMyCommand(ctx context.Context, args []string, stdin io.Reader, stdout, stderr io.Writer) error {
// args[0] is the command name ("mycommand"), args[1:] are arguments.
// Write output to stdout, errors to stderr.
// Return nil on success, or interp.ExitStatus(n) for non-zero exit codes.
}
ctx in every unbounded loop. Builtins that iterate over
input, emit values in a generator-style loop, or do any other work
that can exceed a few milliseconds MUST check ctx.Err() on each
iteration and return it verbatim when non-nil. Hook timeouts rely on
this: an unbounded builtin that never polls ctx cannot be interrupted
by a hook's timeout_sec, and the hook runner will have to abandon
the goroutine (see internal/hooks/runner.go). Returning ctx.Err()
(not interp.ExitStatus(n)) lets callers distinguish "command exited
non-zero" from "we ran out of time".
for _, item := range items {
if err := ctx.Err(); err != nil {
return err
}
// ... process item
}
nil for success, interp.ExitStatus(n) for
non-zero exit codes, or ctx.Err() on cancellation. Write error
messages to stderr before returning.builtinHandler() is already registered
in standardHandlers().| Command | File | Description |
|---|---|---|
jq | jq.go | JSON processor using github.com/itchyny/gojq |