TL;DR: On macOS/Linux: curl -fsSL https://lingcode.dev/install.sh | sh. On Windows: download the Bun zip from /cli. Run lingcode for the REPL or lingcode ask --provider deepseek "…" for one-shot. Works with all 13 providers and reuses keys from the desktop app's Keychain.
LingCode the IDE is great for interactive work. LingCode the CLI is for everything that isn't — scripts, server jobs, one-shot prompts from a terminal you already had open, agent work in places the Mac app can't go.
An "AI IDE" sounds like an application you sit in front of and click through. Most of the time, that's the right shape. But agent loops are useful in plenty of contexts that aren't a foreground GUI: a script that runs every commit. A code-review check on a remote box. A nightly job that summarizes yesterday's diffs. A small backend that exposes the agent to your own internal tools. All of those want a terminal interface — sometimes scripted, sometimes interactive, never tied to a window.
The lingcode CLI is the same agent loops the Mac app runs, just exposed differently. Three independent loops underneath — Claude via the Anthropic SDK, DeepSeek native, and thirteen OpenAI-compatible providers — all reachable from one binary. Five user-facing modes: ask for one-shot prompts, repl for an interactive terminal chat, serve for a local HTTP API, plugin for installing and managing plugins, and doctor for diagnosing your setup. Multiple permission decisions (interactive TTY prompts, auto-accept, deny-all) so you can pick the right safety level for the context.
This tutorial gets the binary onto your shell $PATH, walks the modes you'll actually use day-to-day, and explains the permission model — which matters more in CLI contexts than in the app, because the CLI is the one you'll be tempted to point at unattended jobs.
lingcode from inside the Mac applingcode asklingcode serve as a local HTTP APIlingcode doctor when something's misconfiguredThe CLI ships as part of the LingCode .app bundle — it's at Contents/Resources/bin/lingcode. You don't need a separate download. To put it on your shell $PATH, in the Mac app open the command palette and run Install lingcode Shell Command. LingCode creates a symlink from ~/.local/bin/lingcode into the bundle.
Confirm in a terminal: which lingcode should print /Users/<you>/.local/bin/lingcode, and lingcode --version should print a version like 0.8.x.
which lingcode finds nothing, your shell isn't reading ~/.local/bin. Add export PATH="$HOME/.local/bin:$PATH" to your ~/.zshrc (or ~/.bashrc) and reopen the terminal.
askRun lingcode ask "explain what this script does" -f deploy.sh and the agent reads deploy.sh and prints an explanation to stdout. Pipe-friendly: cat error.log | lingcode ask "what's wrong here?" sends the log on stdin and gets a diagnosis.
Pick the provider with --provider: --provider claude, --provider deepseek, or any of the OpenAI-compatible names. Without that flag, lingcode ask uses whatever default you've configured.
repllingcode repl drops you into a chat loop in your terminal. Same agent loops as the app, same tool use, same provider selection — just text in, text out.
Inside the REPL, use slash commands for control: /provider claude-opus-4-7 switches mid-conversation (same trick as in the app), /model picks a specific model variant, /clear resets history, /exit quits. Tab completion suggests commands.
serveRun lingcode serve and the CLI starts an HTTP server (default port 7437) that exposes the agent over a small REST surface. The main endpoint is POST /v1/agent/ask which streams Server-Sent Events as the agent works — you get progressive output as it streams in, the same way the Mac app's chat panel does.
Auth is a bearer token written to ~/.lingcode/server.token on first start. Pass it in Authorization: Bearer <token>. This is your token, not a shared secret — anyone with the file can talk to your server.
The point of serve isn't to expose the CLI to the internet (don't); it's to let your own scripts and editors and one-off tools call the agent without re-implementing the loop. Useful when you want a Slack bot, a Raycast extension, or a CI step that asks an agent something.
serve to 0.0.0.0. By default it listens only on 127.0.0.1. The bearer token is enough to keep local processes honest; it is not enough to make this safe over the open internet.
In the app, when an agent wants to run a destructive tool call, you see a dialog. In a CLI, dialogs don't exist. So the CLI ships three permission policies, picked with --permission-mode:
tty (default) — when a destructive call is proposed, the CLI prompts you in the terminal for y/N. Safe interactive default; useless for unattended jobs.deny-all — every destructive call is denied. The agent can read, but can't write, exec, or modify. Good when you want analysis only ("explain this codebase") and don't want side effects.yolo — every call is auto-approved. Only when the surface is already isolated (a fresh container, a throwaway VM, a worktree you're prepared to delete). The name is a warning.Pick the smallest policy that lets the job finish. Most CI jobs want deny-all. Most local exploration wants tty. yolo is a knowingly-dangerous setting and should feel that way.
doctorlingcode doctor walks every external dependency the CLI relies on and reports state: Node runtime found and version, agent-bridge subprocess can launch, API keys present in Keychain, CLAUDE.md exists in cwd, MCP servers configured, hooks installed. Each item is green / yellow / red with a remediation note.
When the CLI mysteriously refuses to run, doctor is the first thing to try. The same diagnostic also runs as /doctor inside the REPL.