FAQ: Is localhost You, or the Box?

Your agent just printed Listening on http://localhost:3000.
Did you open that URL on your laptop?
Which loopback answered, yours or the remote box?

I keep seeing this mix-up in agent transcripts.
The model talks like the process sits beside you.
A free remote server does not share your loopback.

Why this FAQ exists

Agents love starting dev servers for you.
They also love curling those servers next.
Those two habits collide on a borrowed machine.

I run cheap agent loops on a remote box on purpose.
Disclosure: This article was prepared as part of MonkeyCode's product outreach.
MonkeyCode offers free model access and a free server option.
I treat that box as a stranger's host, not a laptop clone.

Want a corrected mental model?
Ask one question after every bind: whose localhost?
The chat log cannot answer that question.
The host can, if you probe it.

Myth 1: The log said localhost, so it is my browser

The log is a string from a process.
That process inherited one network namespace.
Your laptop browser uses a different namespace.

Open the pretty URL later if you want.
First prove a listener on the same host.
ss and curl beat a cheerful chat line.

Run this on the box the agent used:

echo "HOST=$(hostname) USER=$(whoami) PWD=$(pwd)"
ss -lntup 2>/dev/null | sed -n '1,40p' || netstat -lntup | sed -n '1,40p'
curl -sS -m 2 -o /tmp/local_body -w 'code=%{http_code} ip=%{local_ip}\n' \
  http://127.0.0.1:3000/ || echo 'curl-on-box-failed'

Did ss show a listener on that port?
Did curl run on the same machine as the log?
If you curled from your laptop, you tested another loopback.

Myth 2: Binding 0.0.0.0 publishes the app to the internet

0.0.0.0 means every local interface.
It does not punch a cloud firewall.
It does not map a port onto your laptop either.

Ask the box what it can actually see:

ip -4 addr show
ip -4 route show
command -v nft >/dev/null && sudo nft list ruleset | head

Still blocked from your browser?
Then the bind succeeded and the path failed.
Those are different bugs. Stop merging them.

A free server may sit behind NAT.
Your agent cannot see that topology from a log line.
Do not mint a public URL from a bind message.

Myth 3: The process survives the chat turn

Did the tool spawn a daemon?
Or a child that dies when the shell exits?
Agents blur that line in almost every session.

Check the parent, not the slogan:

ps -eo pid,ppid,sid,stat,etime,cmd | awk 'NR==1 || /node|python|ruby|java|uvicorn|next/'
echo '---'
pgrep -a node || true
pgrep -a python || true

STAT of Z means zombie.
No row means the process already left.
An etime of a few seconds may mean it just spawned.

I do not trust "server is running" text.
I trust a live PID plus a live socket.
Anything else is narration wearing a port number.

Myth 4: Last session's PID is still the live server

Free boxes get reused across chats.
PIDs wrap. Workspaces get dirty.
Your previous node process is not a lease.

Write a canary the current process owns.
Do not reuse a PID you remember from yesterday.
If the canary hostname changed, you changed hosts.

CANARY=/tmp/host-probe-${USER}.txt
python3 - <<'PY'
import os, socket, time, json, pathlib
path = pathlib.Path(os.environ.get("CANARY", "/tmp/host-probe.txt"))
doc = {
    "ts": time.strftime("%Y-%m-%dT%H:%M:%SZ", time.gmtime()),
    "hostname": socket.gethostname(),
    "fqdn": socket.getfqdn(),
    "pid": os.getpid(),
    "cwd": os.getcwd(),
}
path.write_text(json.dumps(doc, indent=2) + "\n")
print(path)
print(path.read_text())
PY

Label this a recipe, not a benchmark I already ran.
You should run it on the box before you trust a PID.
If hostname in the file != hostname in the chat, stop.

Myth 5: curl localhost in the tool trace proves it works for you

The tool ran curl beside the server.
That path never left the box.
Your browser path includes DNS, VPN, and firewalls.

Same status code. Different route.
A 200 on-box is not your laptop 200.
Did the agent curl 127.0.0.1, or did you?

Split the evidence on purpose:

1. On-box: curl -sS -D- http://127.0.0.1:PORT/health
2. On-box: ss -lnt | awk '$4 ~ /:PORT$/ {print}'
3. Off-box: only after you know a reachable address

Skip step 3 if you have no ingress.
That is normal on a free remote box.
It is not a failed app. It is topology.

Artifact: host identity probe plus a decision table

Save this as host-probe.sh.
Run it in the same session the agent used.
Compare stdout to the chat claim, line by line.

#!/usr/bin/env bash
set -euo pipefail
PORT="${1:-3000}"
CANARY="/tmp/host-probe-${USER:-unknown}.txt"

echo "== identity =="
echo "date_utc=$(date -u +%Y-%m-%dT%H:%M:%SZ)"
echo "hostname=$(hostname)"
echo "whoami=$(whoami)"
echo "pwd=$(pwd)"
echo "uname=$(uname -srm)"

echo "== network =="
ip -4 addr show 2>/dev/null || ifconfig
ip -4 route show 2>/dev/null || netstat -rn

echo "== listeners on :${PORT} =="
if command -v ss >/dev/null; then
  ss -lntup 2>/dev/null | awk -v p=":${PORT}" 'NR==1 || index($0,p)'
else
  netstat -lntup 2>/dev/null | awk -v p=":${PORT}" 'NR==1 || index($0,p)'
fi

echo "== on-box curl =="
set +e
curl -sS -m 2 -D- -o /tmp/host-probe-body \
  "http://127.0.0.1:${PORT}/" | sed -n '1,20p'
CURL_EC=$?
set -e
echo "curl_exit=${CURL_EC}"

echo "== canary =="
python3 - "${CANARY}" <<'PY'
import json, os, socket, sys, time, pathlib
path = pathlib.Path(sys.argv[1])
doc = {
    "ts": time.strftime("%Y-%m-%dT%H:%M:%SZ", time.gmtime()),
    "hostname": socket.gethostname(),
    "pid": os.getpid(),
    "cwd": os.getcwd(),
}
path.write_text(json.dumps(doc, indent=2) + "\n")
print(path.read_text())
PY

Make it executable, then run it:

chmod +x host-probe.sh
./host-probe.sh 3000

Use this table when the chat and the box disagree.

Chat claim	Probe signal	Believe
Listening on localhost	ss has no :PORT	The log. Not a server.
Listening on localhost	ss has :PORT, laptop curl fails	The box. Not your loopback.
Bound 0.0.0.0	No public address, no ingress	Bind only. Not the internet.
Server still running	No PID, or STAT=Z	The process already left.
Same server as last turn	Canary hostname changed	New host or dirty reuse.
curl in the tool returned 200	You never reached a public URL	On-box health. Not your client.

The table is the mental model.
Chat text is a hypothesis.
Host probes are the evidence.

A tiny bind demo you can label as unexecuted

This snippet prints the socket the kernel actually gave you.
It is a recipe. Run it yourself. I am not citing timings.

# recipe: print the real bind, then exit
import socket

with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    s.bind(("127.0.0.1", 0))
    s.listen(1)
    host, port = s.getsockname()
    print(f"bound host={host} port={port} pid={os_get_pid()}")

def os_get_pid():
    import os
    return os.getpid()

Fix the print to call os.getpid() cleanly if you paste it.
The point is the tuple from getsockname().
Not the string the model invented for the README.

What I actually believe now

localhost is an alias, not a location.
It means this namespace, on this host, right now.
It never means the human's browser by default.

A free model can describe a perfect boot sequence.
A free server can still be a different machine.
Those two facts live in the same workflow.

So I split every "it is up" claim into three checks:

• Process: PID, parent, elapsed time
• Socket: bind address, port, owner
• Path: on-box curl versus off-box reachability

Miss one check, and you debug the wrong computer.
Have you done that this week?
I have, which is why this FAQ exists.

Limitations

This probe does not map cloud security groups.
It does not explain IPv6-only listeners.
It does not handle Docker-in-Docker port publishing.

ss needs permission to show process names.
Some boxes hide that without extra caps.
A missing process column is not proof of absence.

The canary lives in /tmp.
Reboots and image refreshes wipe it.
Do not treat it as durable inventory.

I am not naming models, quotas, or hardware here.
Those change, and I will not invent them.
The host questions stay the same anyway.

Who should not use this approach

Skip this if you need a production deploy path.
A free remote box is not your load balancer.
It is a scratch host for agent loops.

Skip this if policy forbids shared machines.
Secrets, customer data, and private keys do not belong there.
Probe identity. Do not park credentials.

Skip this if you already have working ingress plus CI.
Then your source of truth is the pipeline, not a chat bind.
Use the pipeline logs instead of this script.

Closing

Next time the agent says the app is up, pause.
Ask whose localhost just spoke.
Then run the probe on that host before you open a tab.

If you already have a free remote box, run host-probe.sh once in the same session and paste its identity block next to the chat claim. The disagreement is the lesson.