# Conflict resolution

> What happens when two processes claim the same route, locally or publicly.

routeup prefers loud failure over silent last-wins. A surprise "last writer
takes the route" is a common source of "why isn't my dev server responding"
debugging, so conflicts are explicit.

## Local conflicts

Two processes on one machine claiming the same route:

```txt
default:   fail closed; the CLI prints the owning pid and cwd
orphans:   the agent reaps stale claims when the owning pid is gone
```

For foreground or detached `routeup serve`, run `routeup stop [name]`. Runner
and standalone exposure owners must be stopped from their owning terminal. You
can also choose a different route name.

Routes are owned by a live CLI process, which may be foreground or a detached
serve owner. When that process exits, owner-conditional cleanup releases its
claims and tears down matching tunnels; other claims are untouched.

## Public conflicts

Two clients claiming the same route through the same server:

```txt
default:           409 Conflict; generic message, owner identity not disclosed
grace window:      30s after a disconnect the same token may resume the claim
cross-token:       a held route cannot be reclaimed by a different token
public namespace:  session-only, no grace window, first-come-first-served
```

Owner identity is never leaked to a non-owning client. A scoped token can only
claim within its allow pattern, so conflicts across namespaces are impossible by
construction.

## Why a grace window

A brief network drop or a quick restart should not lose your public name to
someone else. The 30-second grace lets the same token resume its claim after a
disconnect. The public namespace deliberately skips this, its claims are
session-only by design. See [Public namespace](/docs/concepts/public-namespace).