Application service does not persist after Codespace stop and start

Direct answers to your three questions

Can devcontainer.json launch the app automatically on every start? Yes, with caveats. The postStartCommand lifecycle hook runs each time the container starts, including after a stop/start cycle. This differs from postCreateCommand, which only runs once at initial container creation — a common misconfiguration that explains why a service starts on first build but not after a resume. A minimal example:

{
  "forwardPorts": [8080],
  "postStartCommand": "nohup npm start >/tmp/app.log 2>&1 &"
}

The backgrounding (&) matters: if the command blocks, the container start sequence can appear to hang. Redirecting output to a log file gives you somewhere to look when the service doesn't come up.

Does the forwarded port keep the same address? Generally yes for the lifetime of the Codespace — the forwarded URL is tied to the Codespace, not to an individual container run, so the address typically survives a stop/start. What does not survive is the listener behind it: until your postStartCommand brings the app back up, clients hitting that URL get connection failures. So there is an unavoidable gap between "container started" and "app accepting connections." Treat the URL as stable but the availability as not guaranteed; clients should retry rather than assume the first connection succeeds. I have not verified current GitHub behavior on URL stability across all account types, so confirm with a stop/start test on your own Codespace.

Is there a supported way to keep a process running across stops? No. When a Codespace stops, the container is shut down and all processes and in-memory state are destroyed. Only disk content under /workspaces (and other persisted volumes) survives. There is no hibernation or process-checkpoint feature. If the requirement is genuinely "reachable at all times," a Codespace is the wrong tool for the serving layer — Codespaces also auto-stop after an inactivity timeout, so even without manual stops the service will go down. The supported pattern is: develop in the Codespace, host the always-on instance elsewhere (any small VM, container host, or platform service), and treat the Codespace's auto-restart as a development convenience.

What is confirmed vs. assumed

• Confirmed by design: processes die on stop; /workspaces persists; lifecycle hooks exist for automating startup.
• Likely but verify: forwarded URL stability across restarts, and exact timing of when postStartCommand runs relative to port availability.
• Assumed: a Node-style app started via npm; adjust the command for your stack.

Quick verification

1. Set "postStartCommand": "date >> /tmp/startlog", rebuild, then stop and start the Codespace. Check /tmp/startlog — a new entry confirms the hook fires on resume.
2. Note the forwarded URL, stop/start, and compare. Also time how long until the app responds, so you know the real gap your clients will see.

One detail that would change this recommendation: is the app stateful in memory (sessions, queues)? If so, auto-restart alone is insufficient — state must be externalized before any stop/start cycle is safe.