fix: reset stale running container on sqrbx resume

[BrettKinny]

Summary

• When a squarebox terminal is closed without typing exit, PID1 bash can stay alive in the container. The next sqrbx call then attaches to a shell that already printed its prompt to the dead TTY, appearing as a blinking cursor with no output.
• sqrbx now stops the container first if it's running, so docker start -ai always attaches to a fresh PID1 bash that paints a visible prompt. Same fix mirrored in install.ps1 for Windows users.
• Preserves the documented "suspends on exit" lifecycle — exit still stops the container normally; no lifecycle drift like a docker exec approach would cause.

Test plan

• Fresh install → sqrbx → exit → sqrbx (normal flow still works)
• sqrbx → close terminal window ungracefully → sqrbx (prompt repaints cleanly instead of blinking cursor)
• Windows pwsh: install.ps1 → same ungraceful-close flow via sqrbx
• Git Bash on Windows: winpty branch still wraps the start command

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Updates squarebox shell entrypoints to avoid attaching to a stale, already-running container after an ungraceful terminal close, ensuring docker start -ai reliably presents a fresh prompt.

Changes:

• Update the generated sqrbx shell function (bash/zsh) to stop the container first if it’s already running, then start/attach (preserving winpty behavior on Git Bash).
• Mirror the same “stop-if-running then start/attach” behavior in the PowerShell profile functions for Windows users.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
install.sh	Regenerates the sqrbx() shell function to stop a stale running container before docker start -ai (with winpty path for MSYS/Git Bash).
install.ps1	Updates PowerShell profile functions to stop the container when running before docker start -ai, matching the Linux/macOS behavior.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

docker stop squarebox | Out-Null suppresses stdout but not stderr, so stop failures can still print noisy errors during sqrbx. If the intent is a quiet best-effort reset (as in install.sh), also redirect stderr or otherwise handle stop failures before proceeding to docker start -ai.

Suggested change

	docker stop squarebox | Out-Null
	docker stop squarebox > $null 2>&1

[Copilot]

The container name is hard-coded as squarebox in the generated shell init. Since this installer already defines CONTAINER_NAME and uses it elsewhere, consider baking that value into the init file via heredoc expansion so a future container rename stays consistent.

Suggested change

	if [ "\$(docker inspect -f '{{.State.Running}}' squarebox 2>/dev/null)" = "true" ]; then
	docker stop squarebox >/dev/null 2>&1 || true
	fi
	if command -v winpty &>/dev/null && [[ -n "\${MSYSTEM:-}" ]]; then
	winpty docker start -ai squarebox
	else
	docker start -ai squarebox
	if [ "\$(docker inspect -f '{{.State.Running}}' ${CONTAINER_NAME} 2>/dev/null)" = "true" ]; then
	docker stop ${CONTAINER_NAME} >/dev/null 2>&1 || true
	fi
	if command -v winpty &>/dev/null && [[ -n "\${MSYSTEM:-}" ]]; then
	winpty docker start -ai ${CONTAINER_NAME}
	else
	docker start -ai ${CONTAINER_NAME}

[Copilot]

The managed PowerShell profile block hard-codes the container name (squarebox) even though the installer uses $ContainerName elsewhere. Consider templating the container name into the profile block (similar to __INSTALL_DIR__) to avoid drift if the name ever changes.