Safety

The agent works with your access, with no prompt before a command or an edit runs and no sandbox, in every mode. This page says what it can reach, what limits it, how to undo its changes, and how Lookout checks its own releases.

What the agent can reach

The agent runs as your user on the machine where the chat runs.

• Its file tools read and write any file your user can, inside the project or anywhere else.
• Shell runs commands with your login shell's environment: your PATH, your tools, your git credentials, and anything else your user can use.
• Browser drives Lookout's own headless Chrome with full access in every mode: local servers, your network and every site, signed in wherever an agent signed in before. It never uses your own Chrome or its sign-ins. Driving a browser.
• Nothing asks before an edit or a command runs. What you could do in a terminal, the agent can do.
• Every mode works this way. A mode is an instruction the agent follows, not a limit: in Ask it answers without changing files. The agent never switches its own chat's mode.

What limits it

• Ignore files. File tools refuse what .gitignore, .lookoutignore or .cursorignore ignore in the chat's folder, and node_modules, .git, dist and .next, by the path the agent names and by where it really leads. Shell commands are not limited by them.
• Overwrites. Write replaces an existing file only after the agent has read all of it, and refuses when the file changed since.
• Links. Write and StrReplace follow symbolic links, as any program does, but never into .git.
• Fetch reads any http or https address the agent names, localhost and your network included. When a public page redirects, the next address must be public too: a redirect from the internet never reaches localhost, a private, loopback or link-local address (such as a cloud's metadata service), and Fetch connects only to the address it checked.
• Connectors. Every connector tool runs unless you set it Off, as Connectors describes.
• Worktree files. A project's .lookout/worktree.json runs its commands and sets the shell's PATH and variables only after you approve it on that machine, as Worktrees describes.
• Worktrees. In a worktree chat, a file tool's relative path and the folder a command starts in stay inside the worktree. Absolute paths reach anywhere, and so can the command itself.
• Tool hooks. Commands you or the project set up can check each tool call before it runs and refuse it, as Tool hooks describes.

Tool hooks

A hook is a command Lookout runs before a tool call. It reads the call as JSON on its input and can let it run, change its arguments, or refuse it; a refused call doesn't run, and the agent gets the hook's reason as the call's result.

A Claude Code hook sees the call the way Claude Code would show it: Shell is Bash (or Monitor when it watches a command), StrReplace is Edit, and the arguments carry Claude Code's names. It follows Claude Code's rules: exit code 2 refuses the call with what the hook wrote to its error output, other exit codes let the call run, and a JSON answer can allow, deny or rewrite it. Lookout never asks you before a call, so a hook that answers ask refuses it. The same command in two files runs once.

A project's hooks run code from the repository, so they wait for your approval. Project settings shows each command under Tool hooks with Approve; on a machine without the app, lookout_configure_project with approveHooks set to the fingerprint lookout_projects shows. One approval covers every worktree of that repository. A hooks file that changes waits again. Until then, the first call in a chat that the hooks would check tells the agent they didn't run, and in every chat of the project the connectors chip under the message box says Hooks not approved (or Hooks need approval after an edit); its Review opens Project settings at Tool hooks. An agent's chat has no such chip.

Lookout's local server

The Mac app and the lookout command run a server on your machine. It answers this machine only: it refuses to start on an address other machines can reach, and it refuses a request that arrives from one.

Other programs on the machine can reach it all the same, so the server answers only a request that carries the app session, a secret in ~/.lookout that only your user can read. The app's window holds it, and Lookout's own clients, such as the lookout command and the plugins for other apps, read it from the file for you. Every other caller is refused: a program running as another user or inside a sandbox, which cannot read the file, and a page in your browser, which cannot call the server in your place. A tool that called the server before this, such as a script or an editor plugin, now gets a 401 back until it is updated to present the session.

That is a boundary between the machine's users, not between your programs. Any code running as your macOS user can read ~/.lookout and use the server as you. The Recovery Key, your devices, the account session and which apps may add projects (App access) are the Mac app's alone: a local client that holds the session is still refused them.

Undo what it did

Every turn that changes files leaves a checkpoint: review the changes and put files back from the side pane, as Checkpoints and changes describes. A checkpoint covers the chat's folder only. It can't undo what a command did elsewhere: a git push, a database write, a package installed globally, a file changed outside the folder.

Signed releases

Every Lookout release is signed with Lookout's release key. The Mac app's updater, the CLI's installer and lookout upgrade each install a release only when its signature verifies against the key built into them. An update without a valid signature is not installed. Which signed releases may install is signed with the same key: a release Lookout has pulled is never installed, and the CLI goes back to an older release only when Lookout signed that rollback.

Release key

Release key fingerprint: c547 1fd3 2fcf 8022 bcab 4265 2ada 476b 3c46 129e 4024 4f24 0d17 1cc3 ac3f beb0

The first install of the CLI trusts the installer you download. To check it before it runs, save it instead of piping it to sh: in the install line below, replace | sh with -o install.sh.

curl -fsSL https://lookout.itoowasinarcadia.com/install.sh | sh

Then print the fingerprint of the key inside it:

sed -n 's/^ *RELEASE_KEY="\([A-Za-z0-9_-]*\)".*/\1=/p' install.sh | tr '_-' '/+' | base64 -d | shasum -a 256

The output starts with the fingerprint above, without its spaces. On Linux, use sha256sum in place of shasum -a 256. When they match, install with sh install.sh.

What an export contains

Export in a chat's menu saves the chat as a .zip:

• every message, tool call and result, and the chat's settings
• its to-do list and the token usage of each turn
• the diffs between its checkpoints
• the files it referenced: long tool output, attached images and terminal logs
• a README that says what is where

The archive holds what the chat saw, so it can contain secrets: file contents, command output, and the values of files such as .env in its diffs. Read it before you share it.