CLI reference

The taiku CLI creates collaborative terminal sessions, manages authentication, exposes tunnels, and configures filesystem sandboxing. This page is a reference for the main commands and options. For real-world usage patterns, see Scenarios and Common Workflows.

taikuCopy Anchor Link

Start a new collaborative terminal session. This is the primary command. Running taiku with no subcommand creates a session, connects to the server, and opens the session URL in your browser or desktop app.

taiku [OPTIONS]

When you run taiku, it:

1. Resolves your authentication credentials.
2. Connects to the taiku server to register the session.
3. Spawns a local shell process (your default shell, or the one specified with --shell).
4. Opens the session URL in the taiku desktop app (or browser, depending on configuration).
5. Copies the session URL to your clipboard.
6. Streams terminal I/O between your local shell and the server until you exit.

Inside a taiku session there is nothing to start, so a bare taiku typed at the prompt opens taiku agent instead. Any flag or subcommand, or output piped to another program, keeps the normal behavior.

OptionsCopy Anchor Link

What a sandboxed shell getsCopy Anchor Link

Every shell a guest opens from the session's plain links is confined to one directory, in isolated mode: the --sandbox directory, or without it the directory taiku started in (its git repository root, if there is one). It is read-write unless you started with --sandbox-ro. With --sandbox-ro those shells are read-only, even for a person you gave read-write access, and people on the links can't upload, save, rename or unzip files through the app either, or approve read-write access to a path. A person you let ignore sandboxing still gets an unsandboxed shell. The --no-sandbox-bridge-auth and --no-sandbox-*-auth options apply to those shells too, including a person you granted trusted. The options that would widen them are not applied: --sandbox-mode trusted, the --sandbox-bridge-auth and --sandbox-bridge-*-auth options, and taiku new --no-sandbox / --trusted. Shells opened from the Admin link are not sandboxed at all, and neither are your own shells on a plain link when the tab is signed in to the account that started the session. Only the Admin link's shells use this machine's own agent logins: agents in your plain-link shells keep a login for your account, separate from this machine's, and start signed out until you sign them in there.

To share a session with guests, pick a project folder for --sandbox. If the folder is your whole home folder, or a folder above it, guests get no shell: you can still work in the session yourself, taiku says so when it starts, and each guest is told to ask you to pick a project folder. You see a notice on the page the first time each guest is turned away. Whatever folder you pick, a guest's shell can't read your SSH and GPG keys, your cloud and Git logins (such as ~/.aws, ~/.netrc or ~/.config/gh/hosts.yml) or your agents' saved logins. In isolated mode it can't read your shell startup files (~/.bashrc, ~/.zshrc and the like) either.

To make a signed-in guest's shells read-only, tick Read-only (block writes) in their sandbox choice and then pick their role, either when you admit their request to join or later from their row in the people list. The same choice offers Ignore sandboxing, which runs that guest's shells with no sandbox. A guest who has not signed in has no such choice of their own; their shells follow the session's default, which you can only change in the desktop app, under Sandbox shared shells when you share a local session. Either change applies to shells opened after it.

An isolated shell never reaches your agent logins, whatever --agent-credentials says. A guest who signed in to taiku can sign their agents in inside their shell and keep that login in their private folder; anyone else finds their agents signed out. API keys and tokens in the environment you start taiku from (ANTHROPIC_API_KEY, OPENAI_API_KEY, GEMINI_API_KEY and anything ending in _API_KEY, _TOKEN or _SECRET) are removed from every shell taiku opens, the Admin link's included. To run an agent on your own login, start it from the Admin link.

A trusted shell that --agent-credentials lets use your login gets a copy of it in a folder of that person's own, one per agent, and never your agents' settings, hooks or plugins. What their agent writes there stays there. If their agent refreshes the login, yours may need signing in again. This holds for your own sandboxed shells too (taiku --sandbox <PATH>): agents in them run on a copy of your login, without your agents' settings, MCP servers, skills or history, and a refresh there can sign you out elsewhere. The copy is made on Linux and macOS only; on Windows no copy is made, and a shell there is not sandboxed (see --sandbox). When taiku runs its shells as another user, no copy is made and their agents start signed out.

What is copied is the file each agent keeps its login in. Two of them hold more than one credential and are copied whole: Gemini's .gemini/.env (every variable in it, not only GEMINI_API_KEY) and OpenCode's auth.json (the key for every provider you signed in to). From Claude's .claude.json only your Console API key and a few first-run settings are copied, and from Gemini's settings.json only the sign-in method.

The copy follows your login each time one of that person's shells starts: when you sign in, change or rotate a key, their next shell gets the new one. When you sign out, the copy taiku made is removed at their next shell start, unless their agent has since refreshed it or they changed it themselves. A shell that is already running keeps what it had until it is closed.

Guests use their own agent loginsCopy Anchor Link

When someone joins with a taiku account, their sandboxed shells keep their own Claude, Codex, Gemini, OpenCode, Amp and Cursor logins (unless you start the session with --agent-credentials host), their shell history, and (in the default isolated mode) their home directory in a private folder on your machine that other guests' shells can't read. Your own agent logins do not reach a guest's sandboxed shell; see What a sandboxed shell gets.

The folder lives on your machine, so you can read it. taiku tells each guest that the first time one of their shells opens, along with where the folder is, and tells them again if what it can promise changes (a later shell without a sandbox, say, where every other guest can read it too). They can run taiku-forget in their shell to delete it, and taiku deletes it anyway once they haven't opened a shell on your machine for 90 days. A guest whose shell is still open keeps their folder however long they stay connected.

If you would rather not hold anyone else's logins at all, start the session with --guest-data session. Each guest's folder then goes when their last shell on your machine exits, and taiku tells them that instead of telling them about the 90 days. A guest with two panes open keeps it until the second one closes, and taiku-forget still works if they want it gone sooner. The cost is theirs: they sign in to their agents again on every visit.

Guests who sign in use their own agent logins, and by default a guest who does not sign in gets no agent at all. That is the point: without an account there is no identity to attach a login to, so the only one left to use would be yours, billed to you and signed in as you. A visitor who wants an agent signs in and brings their own.

--agent-credentials changes that, for sessions started with taiku itself (taiku new, taiku share and the desktop app always use the default, own). With own-or-host a guest with no account falls back to this machine's logins, which is how taiku behaved before the setting existed. With host everyone runs on your logins, signed in or not, which is what you want when you are pairing on your own subscription and not what you want with a link you posted somewhere.

It only reaches guest shells the sandbox does not decide for: shells a signed-in guest runs with Ignore sandboxing, shells in a session whose default is no sandbox, and every guest shell on Windows, which has no sandbox. In an isolated sandboxed shell on macOS or Linux neither choice hands over your login, because the sandbox never grants your agents' config. With host, a signed-in guest's saved login is not used there either: they start signed out, and a login they make in that shell is kept in their private folder.

Shells opened from the Admin link keep your native login under all three. The link taiku copies to your clipboard is the write link, for sharing: open it yourself while signed in and you get a sandboxed shell like a guest's.

A guest without a login who runs claude, codex, gemini, opencode, amp or cursor-agent is told why it will not start. In a sandboxed shell on macOS or Linux that is backed by the sandbox: the shell is never granted your agent's config directory, so there is nothing to reach. On Windows, and in a shell you let run without the sandbox, the refusal and an empty config directory are all there is, which stops a guest finding your login by accident but not one who goes looking for it. On Windows, opencode, amp and cursor-agent can't yet be pointed at a signed-in guest's own login, so unless you chose host they are turned off for that guest rather than left to run on yours.

A guest's shell also can't connect to the local sockets your programs listen on: your ssh-agent, your docker daemon, your session bus and desktop keyring, a tmux server you left running. Any of those would do things for them outside the sandbox. This holds in trusted mode too, which shares your shell config and tools but not those. Sockets inside the workspace still work, and a guest's temporary folder is in the workspace, so a socket their own program makes there works too. Where a guest can run tmux at all (see below), it runs a server of its own.

What a guest loses beyond that depends on the machine, and taiku tells them which case they are in rather than leaving them to guess at a permission error. On macOS, sockets outside the workspace are refused whoever created them, so tmux and a local database socket don't work in a guest's shell. On Linux from 7.1 a guest keeps every socket their own programs create. On older Linux kernels, which can't tell a guest's socket from yours, they get none at all.

Terminals inside a guest's shell have their own trade-off. On macOS, and on Linux where a guest can't open a private terminal namespace (recent Ubuntu blocks that by default), a guest's shell keeps the terminal it started with but can't open new pseudo-terminals, so tmux, ssh -t, script and expect don't run in it. Where a private terminal namespace is available the guest gets those back, but then its shell can't name its own terminal by path: tty prints "not a tty", so GPG_TTY=$(tty), GNU screen and sudo's per-terminal tickets don't work there. Either way the terminal still reads and writes normally, and a trusted guest keeps yours untouched.

On Linux kernels older than 6.2, the sandbox can't tell which files a shell may shorten by name, so it refuses all of them. Inside a sandboxed shell, a program that truncates a file by path fails with "Operation not permitted", even in the workspace: Go's os.Truncate, Python's os.truncate(path), Ruby's File.truncate and Perl's truncate. Programs that open the file and truncate it, like shell > redirects, coreutils truncate, sqlite and Node, are unaffected. io_uring is also off there, so software that needs it and has no fallback fails with "Function not implemented". The shell says so when it starts. Newer kernels have none of these limits.

taiku newCopy Anchor Link

Start another taiku session from this machine, in addition to any you already have running.

taiku new [PATH] [OPTIONS]

PATH is the directory the new session starts in (defaults to the current directory).

taiku localCopy Anchor Link

Start a local-only session on a loopback server, with no traffic leaving your machine. Useful for working offline or keeping a session fully private.

taiku local [PATH] [OPTIONS]

It takes the same PATH and sandbox options as taiku new, plus:

taiku local runs its own loopback server. The taiku inside the desktop app has that server built in, so it needs nothing else. The CLI installers (the install script, Homebrew and the CLI downloads) ship a taiku without it, so there it needs a taiku-server binary, which you build from source. taiku uses --server-bin if you pass it, then TAIKU_SERVER_BIN, then its own built-in server, then a taiku-server next to the taiku binary.

taiku tuiCopy Anchor Link

Work in your session from the terminal itself, with no browser and no desktop app. The toolbar, your tiles and the session's panels are drawn in the terminal you are already sitting in.

taiku tui [OPTIONS]

Press prefix+b for Tiles & Users: who is in the session, their tiles and yours, and a jump to any of them. --no-tui is the way to check what a command would connect to from a script, without taking over the screen.

Useful over SSH, on a machine with no display, or any time leaving the terminal costs more than the browser view is worth.

taiku agentCopy Anchor Link

Hold a conversation with one of your agents in the terminal.

taiku agent [OPTIONS] [AGENT]

Pass an agent's name to open it directly, or leave it off to pick from the ones you have. --server, -C, --cwd, --theme and --no-tui work as they do for taiku tui, plus:

Modes run from read_only (reads, never writes or runs anything) through plan, guarded and auto to unattended. Where an agent may reach is decided on the server and cannot be widened from the command line.

On macOS and Linux, a --local agent is confined to the directory you started it in, the way a taiku terminal already is, so two people working on one machine do not reach each other's files. Windows has no such boundary to install, so the agent runs unconfined there and says so on startup. It keeps its own settings and login, and its tools can still use the network and run programs. If something it genuinely needs lives elsewhere, name that directory with --sandbox-rw or --sandbox-allow rather than turning the boundary off.

One case the boundary cannot cover on its own: on macOS, claude signed in through your Keychain reports Not logged in inside the sandbox, because a confined program cannot read the Keychain, and running /login again will not change it. taiku says so on startup when it applies. Two ways on:

claude setup-token            # then export CLAUDE_CODE_OAUTH_TOKEN
taiku agent --local claude    # works confined, using that token

or start the session with --no-sandbox to use the Keychain login as it is. Copilot has the same problem on macOS with a gh login in the Keychain: export COPILOT_GITHUB_TOKEN, GH_TOKEN or GITHUB_TOKEN, or use --no-sandbox. Linux and the other agents keep their logins in files the sandbox already allows, and are unaffected.

These three options apply to --local only; ask for them without it and the command says so instead of ignoring them.

In the conversation, / opens commands, /model chooses a model, /mode changes the posture, and /published lists what the agent has published.

This needs a server that runs agents. Point --server at one; if the server has no agent host, the client says so on startup rather than leaving you at an empty picker.

taiku loginCopy Anchor Link

Authenticate with your taiku account. This stores credentials locally so subsequent taiku commands are authenticated.

taiku login [OPTIONS]

On machines with a browser, taiku login opens the OAuth login page. You authenticate in the browser, and the CLI receives the credentials automatically via the device authorization flow.

On machines without a desktop (typical servers or build runners), taiku login prints a sign-in link. Open it in a browser on any device, sign in, and approve the request; the CLI waits, then stores the credentials.

OptionsCopy Anchor Link

Where credentials are storedCopy Anchor Link

Your login goes into the operating system's secure store: the macOS Keychain, Windows Credential Manager, or the Secret Service on Linux. taiku login says which one it used. Where no secure store works, such as a container, a CI runner or an SSH session on a headless machine, taiku says so and keeps the login in a file readable only by you instead: ~/.config/taiku/credentials on Linux, ~/Library/Application Support/taiku/credentials on macOS, or under $TAIKU_CONFIG_DIR when that is set.

If you are already signed in, taiku login reports that account and exits without re-running the sign-in flow, so taiku sessions you start are already authenticated. To switch accounts, run taiku logout first, or taiku login --force to overwrite the existing credentials.

Inside a taiku session, taiku login and taiku logout are unavailable: the session already runs as your signed-in account, so manage credentials from your host machine instead.

taiku logoutCopy Anchor Link

Remove stored credentials and log out.

taiku logout

This removes your login from the secure store and the credentials file. After logging out, taiku commands that require authentication will prompt you to log in again.

taiku sessionsCopy Anchor Link

List the sessions you have running, and how many of your plan's session slots they use.

taiku sessions
taiku sessions --all   # include sessions you have already closed

Each running session prints on its own line with its name and how many people are connected, followed by a summary line such as 1 of 3 sessions in use. On a plan with no session limit the summary reports the count on its own.

Run this when a new session is refused: the count it shows is the same one the limit is applied to, so it tells you exactly which session to close to free a slot. It works from inside a session as well as outside one.

taiku sandboxCopy Anchor Link

Manage the persistent sandbox allow-list. This lets you pre-configure paths that sandboxed sessions can access without specifying --sandbox-allow every time.

taiku sandbox allowCopy Anchor Link

Add a path to the persistent allow-list.

taiku sandbox allow <PATH> [--rw]

A read-only shell, from --sandbox-ro or a guest you made read-only, can read a --rw path but not write it. On a session started with --sandbox-ro, the app refuses read-write approvals from everyone, you included, so run this command on your machine instead.

taiku sandbox denyCopy Anchor Link

Remove a path from the allow-list.

taiku sandbox deny <PATH>

taiku sandbox listCopy Anchor Link

Show all currently allowed paths.

taiku sandbox list

taiku toolsCopy Anchor Link

Install and manage the command-line tools taiku uses, routing each install to the right manager (mise, Homebrew, or your system package manager).

taiku installCopy Anchor Link

Shortcut for taiku tools install.

taiku install [SPEC] [--global]

With no SPEC, it opens the interactive picker.

taiku runsCopy Anchor Link

Maintain the on-disk store that backs Track diffs and the run Timeline. The store lives under .taiku/runs/ in your repo and can grow to hundreds of MB over time.

taiku runs gc                 # prune and compress old run snapshots in this repo
taiku runs gc --scan          # sweep every repo under PATH (default: here)
taiku runs gc --keep-days <N> # keep the last N days, drop older snapshots
taiku runs gc --min-keep <N>  # always keep this many newest runs per repo
taiku runs gc --dry-run       # show what would be reclaimed, change nothing

Run taiku runs gc any time to reclaim that space; your recent history is kept.

taiku whyCopy Anchor Link

Ask why a line is the way it is. The answer names the agent turn that wrote it: the sentence the agent said just before the edit, the request it was working from, and the session it ran in.

taiku why src/app.ts:42              # why this line reads as it does
taiku why src/app.ts                 # every recorded change in the file
taiku why src/app.ts:42 --history    # every commit that touched the line, newest first
taiku why --search "retry"           # find changes by what was said about them
taiku why src/app.ts:42 --open       # open the session that answered

Every answer carries one word for how sure it is, beside the file and commit. exact and partial mean a transcript records the edit itself. turn and run mean the change was watched rather than read, so it is attributed to an agent's turn or to a shell command instead of to one tool call. external means nothing in taiku touched the line. unknown is not the same claim: it means the lookup could not run, so nothing is being said about the line either way.

--json prints the same answer for a script, and the exit code carries the same distinction: 0 for an answer, 3 when a line came back unknown, 2 when the question could not be asked at all (not a checkout, an untracked path, a line past the end of the file), and 1 when --open found no transcript.

Answers come from what taiku recorded while you were working, so a line predating the session has none. Turning on Track diffs (or starting a session with --track-repo-diffs) records shell commands too, which is what lets a line no agent wrote still have an answer.

taiku howCopy Anchor Link

Find a feature by plain words: its demo clip and its docs page.

taiku how share a session     # a feature's name
taiku how btw                 # a slash command
taiku how do I split the screen
taiku how remote desktop --open   # open the clip in your browser
taiku how                     # list every guide

It knows other names for things ("split screen" finds tiled layouts) and fixes small typos, saying what it searched for. When nothing matches it suggests what might, prints a link that opens the docs search with your words in it, and exits 1. See Find a feature.

taiku winpathCopy Anchor Link

Translate paths between Unix and Windows form. Useful when you share the same shell config or scripts across macOS/Linux and Windows.

taiku winpath /c/Users/me           # -> C:\Users\me  (Unix -> Windows; only transforms on Windows)
taiku winpath -u 'C:\Users\me'      # -> /c/Users/me  (Windows -> Unix; -u works everywhere)
taiku winpath --rewrite-line "cat /c/tmp/log.txt"   # rewrite paths in a whole command

The default direction (Unix to Windows) only rewrites when run on Windows; use -u / --to-unix for the Windows-to-Unix direction, which works on any OS.

taiku initCopy Anchor Link

Print shell setup code that adds taiku's terminal helpers to your shell. Run it once from your shell config so the helpers load in every new shell.

# zsh / bash: add to ~/.zshrc or ~/.bashrc
eval "$(taiku init zsh)"
eval "$(taiku init bash)"

# PowerShell: add to your $PROFILE
taiku init pwsh | Out-String | Invoke-Expression

The setup code installs a switch shell function (so taiku switch can change your current directory) along with lightweight wrappers that make taiku's path and tool integrations work smoothly inside your shell. On PowerShell, which reserves the switch keyword, it installs a Switch-Worktree function with an sw alias instead.

taiku switchCopy Anchor Link

Jump between git worktrees and branches with a fuzzy picker. Run it inside any git repository.

taiku switch [NAME] [OPTIONS]

With no argument, taiku switch opens an interactive picker (using fzf or sk if installed, otherwise a numbered list) over your worktrees, branches, and cloud workspaces. Pick one and your shell changes into it. With a NAME, it jumps directly:

• A name that matches an existing worktree changes into that worktree.
• A branch name without a worktree creates one under <repo>/.claude/worktrees/<name>/ and changes into it. Worktrees under this folder travel with a bound cloud workspace in both directions. See Work with git worktrees.
• A name (or id) that matches one of your cloud workspaces opens an SSH session on it. See the cloud section below.
• Anything else prints an error.

Cloud workspacesCopy Anchor Link

If you have cloud workspaces bound to this machine, taiku switch shows them in a cloud section (marked ☁). Selecting one runs taiku cloud ssh: it wakes the workspace if it's asleep and drops you into an interactive shell on the VM, in the project directory, with taiku's shell integration available, so switch works there too (letting you move between branches/worktrees inside the cloud workspace), and so does taiku ctl (it targets the workspace's running session). The section is hidden when you are already inside a cloud workspace.

To change your current directory, taiku switch relies on the switch shell function installed by taiku init. Once that is set up, you can also just type switch instead of taiku switch.

Picker controlsCopy Anchor Link

When the fzf/sk picker is open:

The list is ranked by how often and how recently you switch into each worktree, with the current worktree pinned at the top. Open pull requests for a branch are shown inline when the GitHub CLI (gh) is installed and authenticated.

OptionsCopy Anchor Link

taiku agent-runsCopy Anchor Link

Let this machine run your taiku agents that are set to run on it. The agent's own CLI (Claude Code, Codex, OpenCode and the others) runs here under your login for it, in the agent's folder, inside taiku's sandbox.

taiku agent-runs on       # take agent runs on this machine
taiku agent-runs off      # stop taking them
taiku agent-runs status   # say whether this machine takes them, and where
taiku agent-runs allow ~/src/site    # let agents work in this folder
taiku agent-runs forget ~/src/site   # stop letting them

Runs arrive while taiku bystand or the desktop app is running with remote access on. Choose the machine and the folder in the agent's settings on the dashboard. The folder has to be allowed on that machine first, with allow; an agent with no folder works in its own under ~/.taiku/agents. Folders that hold your home, your settings, or programs on your PATH cannot be allowed. An agent set to read only or plan gets its folder read-only.

On Windows taiku cannot sandbox the agent, so on asks for --allow-unconfined there, which runs the agent with your full access to the machine. Agents set to read only or plan do not run there.

While an agent is working here, from a run or from taiku agent --local, taiku keeps the machine from going to sleep on its own, so a run you left going is still going when you come back. The screen can still turn off and lock. On a Mac it shows in pmset -g assertions as taiku: 1 agent running in this process, one line per taiku process running agents. One run stops holding the machine awake after 12 hours, in case it has hung; set TAIKU_AGENT_KEEP_AWAKE_HOURS to change that, or to 0 to let the machine sleep as usual.

To turn it off for every run on the machine, switch off Stay awake while agents run in the desktop app's Settings, under System access. Runs that start after that let the machine sleep as usual.

taiku bystandCopy Anchor Link

Keep the device online and listen for remote session commands. This is a long-running mode where the CLI stays connected to the server without starting an interactive session, waiting for remote instructions from the dashboard.

--managed marks the device as a cloud workspace agent. taiku passes it itself when it bootstraps a workspace; you do not normally type it.

taiku bystand

Use this on machines that should be remotely accessible but do not need an active session running at all times. While it is running, the device accepts remote Start session commands from the dashboard. The desktop app achieves the same thing with a GUI; taiku bystand does the same without a local window.

Turn a spare machine into a remote dev box. Run taiku bystand on a computer you want to reach from elsewhere, leave it running, and you can start sessions on it on demand from any of your other devices, with no one sitting at it. Pass --remote-access false to keep it online but refuse remote session starts, file browsing, and device commands.

See its screen. On Windows, and on Linux with a graphical desktop, the dashboard also offers View desktop for a machine running taiku bystand. Only the account the machine is signed in to can open it; a request from anyone else is declined.

taiku deviceCopy Anchor Link

Run a command on one of your online computers and receive its standard output, standard error, and exit code without opening an interactive terminal.

taiku device execCopy Anchor Link

taiku device exec "Office Mac" -- /usr/bin/printf '%s\n' 'hello'
taiku device exec "Office Mac" --timeout 60 -- sh -c 'pwd && date'

Use the computer's exact device ID or its unique name from your device list. Arguments after -- are passed literally; use sh -c explicitly when you want a shell to interpret them. The command runs as the local user running taiku on that computer. Its stdout and stderr remain separate, and its exit code becomes the exit code of your local taiku device exec command.

One command can run at a time on each computer. Each output stream is limited to 1 MiB. Exceeding the output or runtime limit stops the command.

Sign in to your account before using this command. The target must have Allow remote access to this device enabled and its desktop app or taiku bystand running. Turning remote access off stops active device commands and refuses new ones. Quitting the desktop app stops its commands; a separately running taiku bystand can still keep the computer reachable. Machine and agent-run credentials are not accepted for this command yet.

Mac sleep reachability is untested, including command delivery while asleep and recovery after wake. Keep the target Mac awake; its online indicator reflects recent check-ins and does not confirm that it can receive a command.

Your account API key carries this command authority, just as it does for remote shells and file access. See Devices & remote access for the access controls.

taiku machineCopy Anchor Link

Add this machine to your account without signing in on it.

taiku machine join

join prints a link, a short code and a QR code. Open the link on any device where you're signed in to taiku and approve the machine. Back on the machine, taiku shows which account approved it and asks you to confirm before it saves anything. Once confirmed, the machine keeps a credential of its own in the OS secure store (or a file only your user can read). It is never your account's key, and it is replaced on its own before it expires.

Removing the machine from your account's device list stops it. Run taiku machine join again to add it back.

taiku codexCopy Anchor Link

Give your ChatGPT login to taiku for Codex on your cloud boxes.

taiku codex login

login runs Codex's own sign-in and opens the ChatGPT page in your browser. It signs in inside a folder of its own, so the login codex already has on this computer is left alone, and hands the new login to your taiku account. Nothing of it stays on the computer. Every new shell on your Linux cloud boxes then starts with codex signed in. Run it again to switch accounts, or after OpenAI refuses the login. Settings → Agent shows whose login taiku holds and removes it.

taiku rd-hostCopy Anchor Link

Serve a machine's remote desktop straight from the CLI, without the desktop app. This is the headless path for a Linux server or CI box that has no desktop window of its own but that you still want to view.

--device-id and --device-token override the host identity that would otherwise come from your saved credentials (or TAIKU_DEVICE_ID / TAIKU_DEVICE_TOKEN). Useful on a shared or headless box that hosts for a different device than the one logged in.

taiku rd-host --session <url-or-id> [--auto-accept | --accept-own-account]

Point it at the session you want the desktop to appear in. --auto-accept approves incoming view requests automatically (useful for an unattended box). --accept-own-account approves requests from the account the machine is signed in to and declines everyone else's, so you can open your own machine's desktop without approving each time. Use one or the other, not both.

taiku remoteCopy Anchor Link

Request remote desktop from inside a taiku session shell.

taiku remote [--session <name>] [--client <id>] [--password <password>]

This command is only available inside a shell that was created by taiku. It is for the case where you are already in a remote taiku terminal from another computer and want to open the host's desktop in the taiku desktop app.

When you run it, taiku sends a remote desktop request to the connected session client. If the host requires manual approval, the command prints that the request is pending and waits for approval, rejection, or timeout. If the host uses password-only access, pass --password.

taiku remote does not start a new terminal session. It uses the session you are already in, and it still follows the normal remote desktop requirements: both sides need the desktop app, the controller must be a different device from the host, and the host's guard mode may require approval.

taiku desktopCopy Anchor Link

See and drive a desktop from the terminal: a macOS VM on this Mac (taiku vm), a VNC server, or the machines and cloud workspaces on your account. Your agents get the same controls over MCP.

taiku desktop                                # same as `taiku desktop ls`
taiku desktop ls [--json]                    # the desktops you can drive
taiku desktop add NAME vnc://HOST[:PORT] [--password-env VAR] [--os mac|linux|windows] [--no-check]
taiku desktop rm NAME
taiku desktop view NAME                      # watch and drive it in this terminal
taiku desktop screenshot NAME [-o FILE]
taiku desktop click NAME X Y [--button right] [--double] [--hold KEY]
taiku desktop move NAME X Y
taiku desktop drag NAME X0 Y0 X1 Y1 [--button right] [--hold KEY]
taiku desktop scroll NAME X Y [--dy N] [--dx N]
taiku desktop type NAME TEXT
taiku desktop key NAME CHORD [--repeat N]    # enter, cmd+space, ctrl+alt+delete
taiku desktop mcp [--desktop NAME]
taiku desktop agents [allow NAME | deny NAME]  # which account machines agents may drive

A running VM shows up on its own, under its name. A VNC server needs add once; the port is 5900 unless the URL gives another. taiku signs in with a VNC password or with none, so a Mac's own Screen Sharing, which asks for a Mac account, can't be added yet. Its password goes in an environment variable named by --password-env, never in the URL, where anyone on the computer could read it while the command runs. add connects before it saves, so a wrong address or password fails there and not on first use.

Signed in, ls also lists the account's machines that stream a desktop and your running cloud workspaces with one, each under its own name. Driving one connects the way a remote desktop tile does: the machine's access guard decides whether it waits for approval or starts right away. Each command connects anew, so a machine set to ask each time asks for every command, while view and mcp keep one connection. A machine that requires a password can't be driven from here yet.

view draws the desktop in Kitty, Ghostty, WezTerm or iTerm2 and passes your clicks and keys through, except two the terminal keeps: Ctrl+] leaves, and Ctrl+G sends the next key with Command (Super on Linux and Windows), since the terminal keeps Command for itself.

Coordinates are the desktop's own pixels, the same as a screenshot's. --os says what a VNC server runs, so agents pick the right shortcuts: cmd+c on a Mac, ctrl+c elsewhere.

taiku desktop mcp serves the desktop tools over MCP: list_desktops, screenshot, click, move, drag, scroll, type, key and wait. For the agents you start with taiku agent --local, taiku mcp enable desktop turns it on. Any other agent can run taiku desktop mcp as a local server.

Agents drive the VMs and VNC servers on this computer as soon as they're there. The account's machines and cloud workspaces stay out of their list until you allow each one with taiku desktop agents allow NAME, since a machine set to start right away would let an agent in with nobody watching. taiku desktop agents shows which are allowed, and taiku desktop agents deny NAME takes one back.

taiku vmCopy Anchor Link

macOS VMs on this Mac, each signed in at its desktop with SSH on, for you and your agents to drive with taiku desktop. Needs a Mac with Apple silicon.

taiku vm                                     # same as `taiku vm ls`
taiku vm ls [--json]
taiku vm create NAME [--cpus N] [--memory GB] [--disk GB] [--ipsw FILE]
taiku vm start NAME
taiku vm stop NAME [--now]
taiku vm ssh NAME [-- COMMAND]
taiku vm ip NAME
taiku vm rm NAME [--force]
taiku vm check

create downloads the newest macOS this Mac can run (about 18 GB, kept for the next VM), installs it, and sets up a user named taiku with autologin and SSH, with no Setup Assistant to click through. After the download it takes about 15 minutes. If it is interrupted, run it again and it picks up at the step that did not finish. --ipsw installs from a restore image you already have instead.

Run create and start in Terminal on the Mac itself: macOS starts VMs only from a signed-in desktop session, not over SSH. The other commands, and taiku desktop, work over SSH too. Apple lets a Mac run two macOS VMs at a time.

check says whether this Mac can run VMs without starting one: whether the VM runner is installed beside taiku, its loopback library loads, and its signature allows Virtualization.

taiku shareCopy Anchor Link

Publish the session you are already in to a shareable link, without interrupting your live terminal. Run it from inside a session you are hosting on this machine.

taiku share [OPTIONS]

taiku share snapshots the running session and moves its hosting onto a server so the link works from anywhere, then prints the URL to send to collaborators. Your terminal keeps running throughout; only where the session is hosted changes. Run outside a session, it prints an error telling you to start one first.

Everyone with the link can type by default. Start the session with --enable-readers if you also want a read-only link to hand out.

To hand the session to a managed machine instead of hosting it from your device, see taiku cloud.

taiku cloudCopy Anchor Link

Provision or reuse a managed cloud workspace for a local project, start file sync, and open a taiku session on the cloud machine.

taiku cloud [PATH] [OPTIONS]

If PATH is omitted, taiku uses the current directory. The local path becomes a binding, so future runs from that same path reopen the same workspace when possible.

Run from inside a session, taiku cloud moves that session's project onto the managed machine and continues there, so it survives device sleep and stays reachable from anywhere.

To set up the live sync and walk away without opening a session, use taiku cloud push. For the reverse, pulling an existing cloud project down to a new local folder, use taiku cloud pull.

OptionsCopy Anchor Link

The default transfer also includes Taiku user preferences that should follow the workspace, such as global .taikuignore rules and tool configuration. Those preferences refresh on later taiku cloud runs. Machine identity, login credentials, active-session state, diagnostics, and sandbox path approvals stay local.

SubcommandsCopy Anchor Link

rebuild [WORKSPACE_ID] [--path <PATH>] [--yes] [--force] replaces the backing machine with the server's current cloud image. Project files are kept; the home folder starts fresh. Omit the id to use the workspace bound to the current directory. It refuses a workspace in active use unless you pass --force.

.taikuignoreCopy Anchor Link

Taiku initializes a global ignore file at ~/.config/taiku/taikuignore the first time an ignore-aware command needs it. That file contains editable default rules for cloud sync and recursive scans, such as node_modules/, target/, .svelte-kit/, and logs.

When you create or sync a cloud workspace, files matching these rules are left out, so build output, dependency folders, and caches don't waste space or time on the machine. The import summary tells you what was skipped, so nothing is silently dropped, edit your ignore rules if you want more or less included.

Add .taikuignore at the workspace root for path-specific rules. Workspace rules are applied after the global file, so they can add ignores or opt back in with ! negation:

private/
archive/
generated-docs/
vendor-notes/
*.log
!private/keep.md
!node_modules/

Blank lines and # comments are ignored. Some feature policies are still separate: markdown scans keep crawl limits and root dot-directory handling, and gitfile worktrees keep cloud-local .git handling so remote git diff works. Ignore files apply to recursive work only; explicitly opening or reading a file is not blocked by the ignore file.

On a Mac, a session in your home folder doesn't look inside Desktop, Documents, Downloads, Library, Movies, Music or Pictures for aliases and notes, because macOS asks for permission the first time anything lists them. If you've already allowed taiku into one, name it with ! in ~/.taikuignore to include it again:

!Documents/

For the end-to-end workflow, see Cloud workspaces.

taiku migrateCopy Anchor Link

Work out what moving this computer to taiku would involve, before creating anything. scan and plan only read; neither starts a workspace.

taiku migrate scan                     # find the projects on this computer
taiku migrate plan --tier pro          # where each one would go, and what fits
taiku migrate apply --tier pro         # create the workspaces and bind them

scan and plan only read. apply is the step that creates workspaces, and it shows you the list and asks before it does.

terminalsCopy Anchor Link

Capture the live tmux windows and herdr workspaces on this computer and review their layout. The review opens as a tile in your taiku session, beside your other tiles: the session you run it in, or, from any other terminal, the session taiku is running on this computer. In a terminal of someone else's session it is refused, and with no session running it opens the development-only review instead. This is read-only: it does not move, restart, detach or close anything.

taiku migrate terminals [OPTIONS]

scanCopy Anchor Link

Finds every project on the machine and measures what a move would actually transfer. The size it reports is the part worth syncing, which leaves out node_modules, build output and other things a remote machine rebuilds for itself, so it is usually far smaller than the folder on disk.

The scan skips folders that hold other people's code rather than yours: build output, package caches, vendored dependencies, and the folders your tools manage for themselves. It always tells you how many it skipped and under which rule. Pass --show-skipped to see the paths, which is how you check that nothing of yours was skipped by mistake.

If a project has git worktrees checked out inside it, the scan says how much of its size they are. They move, because the sync carries them so you can work on those branches from either machine. If you would rather leave them behind, add .claude/worktrees/ to that project's .taikuignore before you apply. The scan cannot tell a live branch from one whose pull request merged last year, which is why it reports the number rather than deciding.

The scan reports the move as a pair, Checked as a move from macOS to Linux, because a filename is only fine or fatal relative to both ends. Moving to a system that treats README and readme as one file is the case that can lose one of them, and the scan lists every such pair per project. Moving the other way cannot lose anything.

By default the scan does not run git. It reads each project's remote from the repository's own config file and leaves the rest blank, because git runs tools that a repository can name for itself, which is fine for your own work and not fine for something you downloaded. Pass --trust-repos when everything being scanned is yours, and the scan will also report uncommitted changes and the date of the last commit.

planCopy Anchor Link

Turns a scan into a placement: a workspace name for each project, whether it would be cloned or uploaded, and anything that does not fit your plan's limits. It never creates a workspace, so it is safe to run before deciding.

applyCopy Anchor Link

Moves each project in the plan onto a cloud machine and keeps it synced. This is the step that provisions, so run it with --dry-run first to see the exact list.

Running it again is safe. A workspace that already exists is reused rather than recreated, so if something fails partway you can simply run it again.

With --ssh, taiku asks the machine about itself before it creates anything there. If the machine is not running the operating system you named, it stops and tells you which one it found, because the whole plan was checked against the wrong rules and continuing would call those files checked. It also says whether that machine already has work in ~/workspace, since binding onto it merges the two sides rather than replacing either, and names any agent tools that are not installed there, and which of your projects it cannot build yet because a toolchain is missing.

Your projects share one machine, each in its own folder, so moving several does not use up several workspaces from your plan. What they do share is that machine's disk, so plan checks the total rather than each project on its own.

Toolchains, agent history and a cableCopy Anchor Link

--install-toolchains puts the Rust, Node and Go your projects need into your home directory on the machine, while the files copy. It needs no admin rights, checks every download against its published checksum, and skips anything already there. What does need admin, like Docker or a system Python, is named with the command that installs it.

--with-agent-history brings each project's Claude Code transcripts and files them under the project's new path, so claude --resume in that folder finds them. It is off by default because transcripts hold whatever was pasted into a session. Your global prompt history stays behind either way.

Each repository arrives working: its settings, remotes, index and hooks go with it once, so git status on the machine matches this one. A Windows machine without git gets it installed into your home, since the repositories are no use there without it.

--direct is for two machines joined by a Thunderbolt or Ethernet cable. Keep --ssh pointing at the machine's normal address and let taiku find the cable:

taiku migrate apply --ssh you@mini.example.com --direct auto

taiku asks the machine for its addresses on its direct links and tries them on every connection, so the cable can be plugged in before, during or after the move, into any port. If you know the address, give it instead, such as --direct fe80::1%en5 or --direct 169.254.3.7.

The files go over the cable whenever it answers and over the normal address when it does not, so unplugging it mid-move slows the sync down rather than stopping it. ssh checks that the machine on the cable is the same one taiku enrolled, by its host key, and refuses it otherwise.

Moving onto a machine you already ownCopy Anchor Link

If you have a machine sitting there anyway, a Mac mini, a Hetzner or EC2 box, a spare desktop, taiku can use that instead of a cloud workspace:

taiku cloud create macmini --ssh you@mini.example.com --target-os macos
taiku migrate apply --ssh you@mini.example.com

The machine has to be reachable from the internet, since taiku's server connects to it: give its public address or a hostname that resolves to one. The server looks the name up itself and refuses one that answers with a private address, so a .local name, a LAN address or a Tailscale name is turned down.

taiku manages its own workspace on the machine and nothing else. It never changes the machine's power state, because over SSH it could not turn it back on, and removing the workspace leaves the machine exactly as it was. Its files live in your own home directory (~/.taiku and ~/workspace), so it never needs root or an administrator account.

If the machine is one you have been using, know that the sync is two-way before you start. Anything already sitting in a project folder there is copied down into your local project, and a file that differs on both sides stays in conflict with each side keeping its own version. Nothing is destroyed, but a machine with existing work will change what is in your local folders. Move those files aside first if you wanted a clean one-way move.

Your projects land in ~/workspace/<project> on a machine you brought, and in /workspace/<project> on one taiku creates. Each project keeps its own folder, and they all share the one machine.

apply installs the sync agent on the laptop for you, and says so. Without one your projects are copied across and then stop moving: the sync runs while a taiku command is running and pauses when it exits. The agent reconciles every minute, so later edits reach the machine within about a minute rather than instantly. Remove it with taiku cloud sync --uninstall.

When you delete the workspace, taiku takes itself off the machine: its key comes out of your authorized_keys, its worker stops, and ~/.taiku is removed. Your projects in ~/workspace stay exactly where they are, because they are yours. If the machine is off or unreachable at the time, the delete still completes and those three things are left for you to remove by hand.

taiku deletes nothing of yours on a machine you brought. On a workspace it created it tidies up folders it no longer syncs, but on your own hardware it leaves every directory alone, including ones it put there. Detaching a project stops the sync and leaves the files.

The machine does not need anything installed first. If taiku is not there, enrolling installs it into your own home directory on that machine, without asking for admin rights. If taiku is already there, yours is left alone.

taiku migrate apply --ssh adds taiku's key for the workspace to the machine's authorized_keys itself, through your own ssh, when that ssh gets in without a password. Its question before the move says so, and so does the dry run. On Windows, or when your own ssh does not get in, it prints the key with a command you can paste instead, as taiku cloud create --ssh always does, and keeps retrying until you have added it, so you can do that whenever suits.

This is the only way to run macOS, because Apple ties macOS to Apple hardware. macOS 12.3 or newer, on either Intel or Apple silicon. Linux is any distribution on x86-64 or arm64: the binary is statically linked, so the age of the distribution does not matter, though a machine without systemd cannot start the worker again after a reboot and taiku says so at enrolment rather than pretending otherwise. Windows is 10 or Server 2016 and newer, on x86-64.

A machine that restarts picks its workspace back up a few minutes after it is reachable again, with nobody logged in. A Mac with FileVault on is the exception: it waits at the unlock screen and runs nothing until someone logs in at it, or on macOS 26 and later logs in over ssh with the account password. taiku tells you at enrolment when that applies. For a restart you plan, sudo fdesetup authrestart on the Mac restarts it past the unlock screen once.

If the machine is older than that, enrolling tells you so in one line instead of leaving you with a workspace that never comes up: taiku runs what it installed before reporting success, so "installed but will not run here" arrives at enrolment rather than as silence afterwards.

Bringing your own Windows machine works the same way, and taiku puts its key where Windows OpenSSH actually reads it. One setting on the machine matters: file sync needs your OpenSSH DefaultShell to be cmd.exe, which is what Windows ships. If yours has been pointed at PowerShell the machine still enrols and the worker still runs, but no files move, so taiku says so in the log rather than leaving you to work it out. To put it back:

Set-ItemProperty 'HKLM:\SOFTWARE\OpenSSH' DefaultShell 'C:\Windows\System32\cmd.exe'

If you would rather not run the machine yourself, taiku cloud create <name> --target-os windows runs one on hardware taiku manages.

On Windows, taiku prints a PowerShell command for the key and puts it where Windows OpenSSH actually reads it, which for an administrator account is %ProgramData%\ssh\administrators_authorized_keys rather than your profile.

Migrating to a Windows workspace is worth a plan --target-os windows first. Windows rejects filenames that are perfectly ordinary elsewhere, and treats names that differ only in capitalisation as the same file, so the plan checks for that and tells you which files would not survive.

A project can come back marked as not fitting, usually because it is larger than your plan's disk limit. The plan lists those rather than quietly leaving them out, so you can move them separately, keep them local, or change plan. See Plans and limits.

Your agent settings and loginsCopy Anchor Link

A move onto a machine you brought with --ssh copies your agent settings across too: Claude Code's settings, hooks, skills, plugins and project trust, Codex's config, the MCP servers, hooks, skills and rules of Cursor, GitHub Copilot, Windsurf and the Devin CLI, your git and shell config, with every path under your home pointed at the machine's home instead. Editor settings (Cursor, Windsurf, VS Code's MCP servers and prompts) land where the editor looks on the machine's OS, so ~/Library/Application Support/Cursor on a Mac arrives as ~/.config/Cursor on Linux.

Logins are split by whether a copy keeps working. An API key or a token file works on two computers at once, so it travels. A Claude Code, Codex or OpenCode sign-in does not: it refreshes by replacing itself, so whichever computer refreshed second would find itself logged out. Those stay here, and apply offers to give the machine its own Claude Code and Codex logins at the end, with the sign-in page opening on this computer. Say no and it prints the taiku cloud login <tool> --workspace <ID> line for each. OpenCode's sign-in is not made for you; the summary names opencode auth login to run on the machine, or taiku cloud login opencode --workspace <ID> runs it there from here. The Cursor CLI's sign-in stays for the same reason, and Copilot's and the editors' live in this computer's keychain; for each, the summary gives the command that signs in on the machine, such as NO_OPEN_BROWSER=1 cursor-agent login or copilot login.

Other secrets only travel when you name them, onto a machine you bring or a taiku cloud workspace alike; taiku cloud leaves them here and says so. --carry-aws-profile and --carry-ssh-key take one profile or key each, and --carry-static-credentials covers the other long-lived logins: Modal, E2B, Hugging Face, Fly, Kaggle, Docker registry logins, gcloud, kubectl and the sops age key that decrypts your sops secrets. Off a Mac it also points git's Keychain helper at the copied ~/.git-credentials. The Devin CLI, Grok and Kimi Code keep sign-ins that refresh, so they log in on the machine instead: taiku cloud login <tool> --workspace <ID> runs each one's sign-in there. Qwen Code logs in with an API key now, in ~/.qwen/.env or its settings, and that travels with its config. Hetzner Cloud, Daytona and Namespace stay too, and the summary names the command that logs each in on the machine. Anything tied to this computer, such as Tailscale or a hardware key, never moves. taiku cloud logins --workspace <ID> shows what is logged in on each side afterwards.

sessionCopy Anchor Link

Moves a Claude Code session you are working in to the machine its project syncs to without starting over. Its herdr pane and name stay on this computer, so you keep prompting and reading it the same way; Claude itself runs on the machine in tmux and keeps going if the connection drops. back brings it home.

taiku migrate session list              # live sessions here and on machines
taiku migrate session move ci-health    # move one by its herdr name
taiku migrate session back ci-health    # bring it back

Before anything changes, move checks that the session is idle, that the machine has the same files and a Claude Code login of its own, and names what will not come along (a dev server running in the project, node_modules). The conversation is copied and checked, Claude is asked to exit, and it resumes on the machine as the same session. Nothing on this computer is set aside until that session is running there; if a step fails, the session runs here again. If a move stops halfway, taiku migrate session repair <name> finishes or undoes it.

memoryCopy Anchor Link

Claude Code keeps what it learns about a project in that project's memory. One computer owns it at a time and it is never merged: handing it over copies it exactly, checks every file, and leaves a two-line note on the other side saying where it went. A session move hands it over for you; these commands do it by hand.

taiku migrate memory status                 # where each project's memory lives
taiku migrate memory take --to <WORKSPACE>  # hand this project's memory to that machine
taiku migrate memory back                   # bring it home
taiku migrate memory review                 # take changes from the other copy, one at a time

review goes through what changed in the copy that is not the owner and asks about each change; only the ones you accept are copied over.

taiku migrate memory importCopy Anchor Link

Bring a project's Claude Code memory into taiku's repository memory. The command reviews each file before importing it and never overwrites a different file already in taiku.

taiku migrate memory import --repository-id <ID>
taiku migrate memory import --repository-id <ID> --dry-run
taiku migrate memory import --repository-id <ID> --yes

The import reads Claude Code's project memory for the selected folder. It preserves the files as written, skips files that are already identical, and leaves a different existing file untouched. Secret-shaped content, unsafe files, malformed metadata, and folders over the import limits are refused before any prompt or write.

taiku ctlCopy Anchor Link

Remote session management. Control a running taiku session from the CLI or from inside a taiku terminal. Commands are relayed through the server to the browser client, which executes them and returns results as JSON.

taiku ctl [--session <name>] <command> [args]

How it works:

• When you start a session with taiku, the session name is written to active-session in taiku's config directory (~/.config/taiku on Linux, ~/Library/Application Support/taiku on macOS). taiku ctl reads it to know which session to target, unless TAIKU_SESSION names one.
• Commands are sent via HTTP to the server, which relays them over WebSocket to a connected client. A session window must be open (browser or desktop app) for commands to work. If nothing is connected, commands time out after a few seconds.
• taiku ctl works inside taiku terminals. It's one of the few commands not blocked by the nested-session guard.
• Use --session <name> to target a specific session instead of the active one.
• Use --client <id> (from list-users) when several participants are connected and you need to control a specific client.
• Use --current on a layout command to act on the tile of the shell the command is running in, rather than whichever tile the answering client has focused. Run from inside a taiku terminal, taiku ctl split-v --current splits the pane you are typing in; without it, the split lands wherever the browser's focus happens to be. --tile <key> names one outright.
• Commands that affect terminals follow the session's normal control model. You can manage your own terminals; other active participants' terminals require handoff or tunnel-admin access.

Layout commandsCopy Anchor Link

Workspace commandsCopy Anchor Link

Shell commandsCopy Anchor Link

Session info commandsCopy Anchor Link

Chat commandsCopy Anchor Link

Agent commandsCopy Anchor Link

Pane commandsCopy Anchor Link

File comment commandsCopy Anchor Link

Other commandsCopy Anchor Link

The remote commands reference covers each command's full options and what it returns. Commands marked "terminal client only" are refused by the browser and the desktop app.

taiku componentsCopy Anchor Link

The CLI and the desktop app update on their own channels, and whichever installed each one (Homebrew, npm, the install script, the desktop installer) should be the one to update or remove it. This command tells you what is installed and routes each action to the right place, so you don't have to remember which channel owns what.

taiku components                   # what is installed, the available version, and who owns it
taiku components update cli
taiku components update desktop
taiku components add desktop
taiku components remove cli

The list also shows the terminal client, which is built into the CLI and updates with it, and the terminal tools taiku manages. The component names are cli, tui and desktop; tui is accepted only so the command can tell you there is nothing separate to install.

taiku never overwrites or deletes a file another installer owns. When the CLI came from Homebrew or npm, update cli and remove cli print the command to run instead (brew upgrade taiku, for example). update desktop opens the desktop app so its signed updater can fetch the new release, and add desktop opens the installer download. remove cli never deletes the binary that is running; it prints the command that finishes the job once it exits.

taiku update follows the same rule.

taiku logsCopy Anchor Link

Manage local diagnostic logs the CLI stores for support and debugging.

taiku logs exportCopy Anchor Link

Export diagnostic logs as an encrypted bundle.

taiku logs export [--output <FILE>]

taiku logs clearCopy Anchor Link

Clear all stored diagnostic logs.

taiku logs clear

taiku logs statusCopy Anchor Link

Show how many log entries are stored and approximate database size.

taiku logs status

taiku skillsCopy Anchor Link

taiku's skills for coding agents (Claude Code, Codex). See Skills for your coding agent.

taiku skills                      # same as `taiku skills list`
taiku skills list                 # each skill, per agent: current, out of date, changed, not installed
taiku skills install [NAME...]    # all when none are named
taiku skills update               # bring installed copies up to this release
taiku skills remove [NAME...]     # all when none are named

update only refreshes skills you already have; it never installs new ones. After you upgrade taiku by any route, the first time you run it outside a session (starting a session, taiku update and so on) it does the same refresh once on its own, skipping any copy you edited. When --force replaces a copy you edited, the old one is kept under ~/.taiku/skill-backups.

taiku skills importCopy Anchor Link

Bring the skills, commands and rules you already use with other coding agents (Claude Code, Codex, Gemini CLI, OpenCode, Cursor, Copilot, Kiro and more) into taiku. Skills from your home folder go to ~/.taiku/skills; skills from the project you run it in go to that project's .taiku/skills.

taiku skills import --dry-run          # see what would happen, write nothing
taiku skills import                    # import
taiku skills import --undo <ID>        # take an import back

The report lists everything it found: what arrived as it was, what changed on the way in and why, what needs a decision from you, and what was not imported and why (a rule that applies to every request, for example, is not a skill). Commands arrive as skills you run by name. The files in your other agents' folders are never changed, and running the import again only brings in what is new.

taiku mcpCopy Anchor Link

MCP servers for the agents you start with taiku agent --local. See MCP servers.

taiku mcp                              # same as `taiku mcp list`
taiku mcp list [--json]                # configured and suggested servers, on or off, signed in or not
taiku mcp add NAME URL                 # a remote server
taiku mcp add NAME -- COMMAND [ARGS]   # a local server taiku starts for you
taiku mcp remove NAME                  # also signs out of it
taiku mcp enable NAME [--agent AGENT]  # for every agent, or one
taiku mcp disable NAME [--agent AGENT]
taiku mcp auth NAME                    # sign in (OAuth)
taiku mcp logout NAME                  # sign out and revoke
taiku mcp debug NAME [--agent AGENT]   # each step of reaching the server, and its tools

The config is mcp.json in taiku's config folder (~/.config/taiku on Linux, ~/Library/Application Support/taiku on macOS, %APPDATA%\taiku on Windows; taiku mcp list prints it), in the same shape as OpenCode's mcp block. Sign-ins are kept in your system's credential store (Keychain, Credential Manager or Secret Service). Where there is none they go in mcp-auth.json beside it, readable only by you, and taiku mcp auth says so.

taiku updateCopy Anchor Link

Check for a newer taiku release and install it.

taiku update
taiku update --check            # only report whether a newer release exists
taiku update --channel nightly  # follow nightly builds from now on

taiku ships on three channels. stable is the default. beta is a nightly that held up and was promoted. nightly is built from the latest code once a day. --channel saves your choice, so later updates stay on it, and installs the newest build on that channel. Going back to stable never downgrades: you stay on the build you have until a stable release passes it.

If you installed the CLI with Homebrew or npm, or it came inside the desktop app, taiku update leaves the file alone and prints the command that updates it properly: brew upgrade taiku, npm install --global taiku@latest, or taiku components update desktop. --check reports a newer release on every kind of install.

Environment variablesCopy Anchor Link