# Green Chat as OpenAI

Canonical wiring guide: **[green-chat-llm.md](green-chat-llm.md)** — OpenAI-compatible env (`OPENAI_*`), discovery, and smoke tests.

This page covers **LAN reachability** when green-chat is bound to loopback only.

---

## Current workstation probe (2026-08-04)

| Check | Result |
|-------|--------|
| Host | `192.168.50.181` (ping OK) |
| Port | `8767` |
| `Test-NetConnection 192.168.50.181 -Port 8767` | **TcpTestSucceeded = False** |
| `curl http://192.168.50.181:8767/v1/models` | Connection timed out |
| Local `http://127.0.0.1:8767` | Something else answers (Windows `ge chat serve` / local GGUF) — **not** the green host |

**Cause (expected):** green-chat on the green machine was started with `--host 127.0.0.1 --port 8767`, so it is not reachable over the LAN.

Descrybe **root** `.env` (or `/integrations/ai`) can still hold:

```env
OPENAI_BASE_URL=http://192.168.50.181:8767/v1
OPENAI_MODEL=overloaded-local
OPENAI_API_KEY=…   # set locally; do not commit
```

…but API/worker calls will fail until bind or tunnel is fixed. Restart **api** and **worker** after any process-env change (dashboard AI keys do not require restart).

---

## Fix A — Rebind green-chat to `0.0.0.0` (preferred)

On the **green machine** (SSH as a user with sudo). Inspect the current unit first:

```bash
sudo systemctl cat green-chat
sudo systemctl cat green-chat.service.d/*.conf 2>/dev/null
ss -tlnp | grep -E '8767|ge|green|chat'
```

Create a drop-in that forces LAN bind (adjust `ExecStart=` to match the real binary/flags from `systemctl cat`; only change `--host`):

```bash
sudo mkdir -p /etc/systemd/system/green-chat.service.d
sudo tee /etc/systemd/system/green-chat.service.d/10-listen.conf >/dev/null <<'EOF'
[Service]
# Clear inherited ExecStart, then set full command with --host 0.0.0.0
ExecStart=
ExecStart=/usr/local/bin/ge chat serve --host 0.0.0.0 --port 8767
# If your unit uses Environment instead of flags, prefer e.g.:
# Environment=GE_CHAT_HOST=0.0.0.0
# Environment=GE_CHAT_PORT=8767
EOF
sudo systemctl daemon-reload
sudo systemctl restart green-chat
ss -tlnp | grep 8767
```

Confirm you see `0.0.0.0:8767` (or `*:8767`), not only `127.0.0.1:8767`. Open the firewall if needed:

```bash
sudo ufw allow from 192.168.50.0/24 to any port 8767 proto tcp
```

Then from **Windows**:

```powershell
Test-NetConnection 192.168.50.181 -Port 8767
curl.exe -sS -H "Authorization: Bearer YOUR_KEY" http://192.168.50.181:8767/v1/models
```

Keep `OPENAI_BASE_URL=http://192.168.50.181:8767/v1` in root `.env` or `/integrations/ai`, restart API + worker if using process env.

---

## Fix B — SSH tunnel from Windows (no systemd change)

If you cannot rebind yet, forward loopback from the green host to this PC:

```powershell
# On Windows (leave this session open)
ssh -L 8767:127.0.0.1:8767 green@192.168.50.181
```

Then point Descrybe at the tunnel:

```env
OPENAI_BASE_URL=http://127.0.0.1:8767/v1
OPENAI_MODEL=overloaded-local
```

**Port conflict:** this Laragon PC already has a **local** green-chat (or similar) on `127.0.0.1:8767`. Stop that local process first, or use a different local port:

```powershell
ssh -L 18767:127.0.0.1:8767 green@192.168.50.181
# then OPENAI_BASE_URL=http://127.0.0.1:18767/v1
```

Restart API + worker after changing `.env`.

---

## Related

- [green-chat-llm.md](green-chat-llm.md) — full OpenAI wiring, discovery, app-level smoke checks
- [ops-runtime.md](ops-runtime.md) — worker / credits