# Update and versions (/docs/v0.4/cli/update)



```bash
koshi update
```

The command checks GitHub Releases. When a newer version exists, it downloads
the archive for the current OS and architecture, extracts `koshi`, and replaces
the running executable.

If the current version is latest, it prints that result and exits successfully.
Network, platform, archive, permission, and install failures return an update
error.

On Unix, replacement uses an atomic rename. A root-owned install may ask for
`sudo` to run `install -m 755`. On Windows, the running executable moves aside
and the new one takes its path; the old image is removed on the next launch.

## The running sessions move too [#the-running-sessions-move-too]

Since 0.3.0 the update does not stop at the binary. `koshi update` then
restarts each running session that can into the new release, and after them the
background process that tracks sessions.

A session keeps its panes, the programs running in them, and their scrollback.
An attached terminal rejoins the session on its own.

<Callout type="warn">
  A session that refuses the restart is named on standard error and keeps the old
  build until you end it and start it again.
</Callout>

A session refuses the restart when:

* a pane's program stopped reading its input;
* a pane has no terminal to carry;
* this machine cannot run the new binary;
* the new binary does not read the resume file this build writes.

A session running a koshi with no restart at all, one that still reports the
old version after the restart, and one that answers nothing within ten seconds
are all reported the same way.

## Which build is running where [#which-build-is-running-where]

```bash
koshi version                  # the koshi program you just ran
koshi server-version           # every running koshi server
koshi server-version --session <NAME_OR_ID>
koshi server-version --format json
```

`koshi version` prints the same line as `koshi --version`:

```text
koshi version
koshi 0.4.0
```

The two answers differ while an update rolls out — the program your shell runs
is a newer build than the process answering it until every swap lands:

```text
koshi server-version
kind     session                                       version
router   -                                             0.4.0
session  session-3f2a1c94-8e7b-4d15-9a02-6c5138ef7b40  0.4.0
session  session-91c4de07-2b53-41a8-bf6e-70d9a2c81f35  0.2.0
```

| Cell                  | Meaning                                                            |
| --------------------- | ------------------------------------------------------------------ |
| a build, like `0.4.0` | The server answered and named it                                   |
| `unknown`             | The server answered and is too old to name its build               |
| `not running`         | Nothing is listening there                                         |
| `unreachable`         | The server could not be asked; the reason prints on standard error |

A server that could not be asked does not sink the rest of the answer: the
other rows still print, and the command exits 4, so a script reading only the
rows never takes a partial answer for the whole picture. Everything answering
exits 0, including a machine running nothing at all.

`--session` reports that one session and leaves out the router. It takes the
session id or its exact generated name, and a name must match exactly one
running session.

## Startup checks [#startup-checks]

Interactive launches can check on an interval and ask before installing:

```kdl title="koshi.kdl"
version 1

update {
    auto-check #true
    check-interval-days 14
    allow-prerelease #false
}
```

Startup check failures never block or crash a normal launch. koshi stores only
the last-check time in its own state file; it never rewrites `koshi.kdl`.

`allow-prerelease #true` chooses the highest semantic version from recent
releases, including pre-releases. Otherwise koshi uses GitHub's latest stable
release.