Scenarios

Use these pages when the default taiku flow is not quite enough and you need to choose the right access model, device setup, or sharing pattern.

CI/CD pipeline authentication

In CI, there is no browser for interactive login. Set TAIKU_TOKEN in your pipeline and run taiku in headless mode:

# GitHub Actions example
env:
  TAIKU_TOKEN: ${{ secrets.TAIKU_TOKEN }}

steps:
  - run: taiku --no-app --no-browser --name "ci-${{ github.run_id }}"

The --no-app and --no-browser flags matter here. Without them, taiku tries to open a desktop app or browser window, which fails on headless runners.

For GitLab CI:

variables:
  TAIKU_TOKEN: $TAIKU_TOKEN

script:
  - taiku -q --no-app --no-browser > session-url.txt
  - echo "Session available at $(cat session-url.txt)"

Use -q if you want stdout to contain only the session URL.

Live collaboration at a hackathon

At a hackathon, the highest-leverage pattern is often one strong host machine with everyone collaborating through the same taiku session.

Start with:

taiku --enable-readers --tunnel 3000 --name "hackathon-demo"

Then use taiku as the shared control plane for the whole project:

• keep one repo checkout per person in separate worktrees on the same machine
• let each teammate or agent own a separate worktree so they can code, test, and merge without stepping on each other's branch state
• treat those worktrees as the main unit of parallelism: one agent per worktree, one line of work per worktree, one clean merge path back to the main branch
• run coding agents from the same host so everyone can inspect the same agent output, token usage, and working memory
• keep project-wide coordination in shared instruction files such as the global CLAUDE.md, so agents in different worktrees still inherit the same task framing, constraints, and merge expectations
• debug using another person's agent context instead of trying to reconstruct what their tool calls and intermediate steps were
• expose the local app with --tunnel 3000 so everyone can see the running result while the coding work continues

This works especially well when:

• one person is driving merges
• others are iterating in parallel worktrees
• agents are generating patches or investigating bugs live
• everyone wants access to the same shells, chat, tunnels, agent history, and project-level instructions

If some teammates are untrusted, or you only want them touching one project tree, start the session with a sandbox:

taiku --sandbox . --enable-readers --tunnel 3000 --name "hackathon-demo"

That keeps the shared session useful while still restricting filesystem access to the working directory. Add --sandbox-allow only for paths the team actually needs.

Sharing progress during scrums or demos

Sometimes you want people to follow progress without affecting the main presentation.

Use:

taiku --enable-readers --name "daily-update"

Share the reader URL broadly and keep the writer/admin URL with the presenter.

That way:

• the presenter keeps control of the main shell
• teammates can open the session and inspect results themselves
• nobody accidentally types into the live demo

If you are also demoing a web app, add --tunnel 3000 or whatever port you are serving on.

Remote programming from a phone

If you step away from your laptop but still need to check logs, review output, copy a command, or inspect files through the workspace, taiku works well from mobile as a companion device.

The practical pattern is:

taiku --name "remote-from-phone"

Then open the session from your phone.

This is best for:

• checking whether a build finished
• reading terminal output and chat
• copying paths, errors, or commands
• viewing the same session state without disturbing your main machine

For the full mobile behavior, see the mobile guide. If you want remote launch from another device, pair this with the desktop app and device management.

Read-only demo with anonymous viewers

You are giving a live demo to an audience that should be able to watch but not type, and you do not want to require viewers to sign in first.

taiku --enable-readers --no-viewer-auth --name "demo: production deploy"

This prints three URLs:

• Reader URL for the audience
• Writer URL for a co-presenter
• Admin URL for the person running the demo

This requires Pro. --no-viewer-auth removes the OAuth viewer gate, but viewers still need the reader URL including its fragment so their browser can decrypt the terminal stream.

Sandboxed agent workspace

If you want to run an AI coding agent inside taiku but keep its filesystem access narrow, start the session with a sandbox:

# Basic sandbox: only the project directory
taiku --sandbox . --name "agent-workspace"

# Claude auth bridging
taiku --sandbox . --sandbox-bridge-claude-auth --name "claude-session"

# Read-only review session
taiku --sandbox-ro --sandbox . --name "code-review"

This is the right pattern when the agent should work in one repo but should not see your whole machine.

If you need extra read paths:

taiku --sandbox . --sandbox-allow /usr/local/lib --sandbox-allow ~/.config/git

If those paths are reused often, persist them once:

taiku sandbox allow /usr/local/lib
taiku sandbox allow ~/.config/git

Headless server with remote access

If you want a cloud VM or home server to stay available from the dashboard, run taiku in bystand mode:

# First-time setup
taiku login --token tk_your_server_token

# Keep the device online
taiku bystand

With taiku bystand running, the device stays reachable and can accept remote session launches without needing a local GUI.