Installer: install into the project when run inside one; stop before login

[htahir1]

Summary

Two changes to the installer from its first real runs, both about it assuming too much.

1. Install into the project when run inside one. The worker is the kitaru package itself, and replays run your agent in the worker's own environment. So a kitaru in an isolated uv tool environment can log in, import, and run evaluators, but never replay your agent. The one-liner installed exactly that and didn't say so. Now:

• Run inside a Python project (pyproject.toml or uv.lock in the current directory): uv add "kitaru[cli,mcp,worker]" into that project's environment; MCP registered as uv run --directory <repo> kitaru-mcp at Claude Code project scope (./.mcp.json); success line names the environment; closing message says uv run kitaru ....
• Run anywhere else: the isolated tool install as before, success line names the environment and the commands, and the closing message says replays need Kitaru inside the agent's project.
• --project / --global (or KITARU_SCOPE) force either. --project without a pyproject.toml fails with "run uv init first, or use --global".

2. Stop before login. Login is the one real decision in the flow (local Docker or the managed cloud), and every edge case the script had accumulated (Docker down, port taken, older server, no terminal) came from guessing it. The script now ends after wiring the coding agent and prints:

  Next, pick where your Kitaru server lives:

    kitaru login --local    local, in Docker. Free, open source.
    kitaru login            managed cloud. 14-day trial, no credit card required.

(In project mode every command is prefixed with uv run, since Kitaru is not on PATH there.)

Merge order: this message assumes bare kitaru login targets the managed cloud, which is #967. Merge #967 first, or the second line points at a command that errors until it lands.

--server URL still points the MCP server at a team server. --no-login is gone.

Docs and README now say to run the installer inside your agent's repository, and describe both modes. The smoke workflow gains a step that runs it inside a uv init project and checks pyproject.toml and uv run kitaru.

Reviewer Notes

• The mode split lives in section 2 of install.sh; everything after it uses KITARU_BIN, MCP_CMD, and CLAUDE_SCOPE and does not care which mode ran. The Claude config snapshot/restore now targets ./.mcp.json in project mode.
• Project mode skips PATH edits entirely (nothing to put on PATH) and relies on uv run.
• Follow-up for repo-scoped setup on an existing install remains Add a kitaru setup command that wires skills and the MCP server into detected coding agents #953 (kitaru setup).

Reproduction

Inside a fresh uv init project: cat install.sh | bash -s adds kitaru[cli,mcp,worker]>=0.24.0 to pyproject.toml, .venv/bin/kitaru --version is 0.24.0, no ~/.local/bin/kitaru is created, and with a claude CLI present .mcp.json contains uv run --directory <repo> kitaru-mcp --server ... --mode standard. In an empty directory the global path runs as before. --version=99.99.99 still exits nonzero. Verified in Docker on ubuntu:24.04 (project) and alpine:3.21 (global).

🤖 Generated with Claude Code

https://claude.ai/code/session_01UrD7eCgTu11F6qsYMS5JMP

[greptile-apps]

Your trial has ended. Reactivate Greptile to resume code reviews.

[strickvl]

#967 is merged in now, so whatever updates need to go into this can be made, and also CI is failing, but otherwise this seems like both fair updates.

[AlexejPenner]

🦭