Which Tares does the tares command talk to when I am signed in with tares login and also have tares up running locally?

Tares sends the tares command to the workspace that tares login saved, not to your local tares up, unless a flag or environment variable points elsewhere. To work against the local Tares, set TARESD_URL=http://127.0.0.1:8787 or run tares logout. The local Tares at that address is the last choice in the lookup order, so it is used only when nothing earlier is set.

How it works

Every command finds its Tares in the same order. The first match wins:

1. A flag, such as --taresd.
2. The TARESD_URL and TARES_AUTH_TOKEN environment variables.
3. The workspace that tares login saved.
4. The local Tares at http://127.0.0.1:8787.

When you run tares login, your browser opens the console’s Connect a terminal page. You pick a workspace and choose Connect. The workspace makes an admin key for this machine and hands it back to the CLI over 127.0.0.1 with a one-time code. The CLI saves the workspace and the key in ~/.tares/login.json, readable only by you.

On a machine that is signed in, step 3 matches before step 4. A tares up running on the same machine is still there, but the command line does not reach it by default. Commands such as tares status, the software factory commands and the Claude Code plugin all follow this same order.

The key is only ever sent to its own workspace and the console. Running tares login again replaces the saved workspace and removes the previous key.

Set it up

Pick the option that fits how long you want to work locally.

1. Check where you are pointed. Run tares status. When you are signed in, the first line of its output says which workspace it is talking to.

tares status

2. To use the local Tares for one command, set TARESD_URL to the local address for that command. Because environment variables come before the saved login, this reaches your local tares up and leaves your login in place.

TARESD_URL=http://127.0.0.1:8787 tares status

3. To use the local Tares for a whole terminal session, set TARESD_URL=http://127.0.0.1:8787 in that shell. Unset it to go back to the saved workspace.

4. If your local Tares has auth on, TARES_AUTH_TOKEN carries an admin key or the root token. tares up --auth exports that variable, so setting it yourself is equivalent. tares status can also read the root token from the data directory.

5. To stop using the cloud workspace on this machine, run tares logout. It removes this machine’s key from the workspace and deletes ~/.tares/login.json. Your browser sessions and other machines are not affected. If the workspace cannot be reached, the file is still deleted and the command tells you where to remove the key by hand.

tares logout

6. To go back to the cloud workspace later, run tares login again.

tares login

What you get

• A predictable rule: a flag beats the environment, the environment beats the saved login, and the saved login beats the local default.
• Your local tares up and your cloud workspace live side by side on one machine. You choose per command or per shell which one answers.
• A quick check with tares status, which names the workspace when you are signed in, so you can see where a command will go before you rely on it.
• A clean exit with tares logout, after which the local Tares at http://127.0.0.1:8787 is the default again.

If you build monitoring on top of this, for example with the setup described in AI SRE, this order tells you which instance holds your sources and triggers when you run commands from the terminal.

When something else fits

• If you only ever use Tares Cloud, you do not need TARESD_URL. The saved login is enough, and the details are in the CLI reference.
• If you only run a local Tares, skip tares login. With no flag, no variable and no saved login, the command finds http://127.0.0.1:8787 on its own.
• If you want one command aimed at a specific daemon, a flag such as --taresd on commands that accept it is more direct than an environment variable.

Related