Skip to main content

Networking & Ops

HTTPS / LAN access​

Access ChatWalaʻau from other devices on your network (phones, tablets, PCs). HTTPS enables the browser Secure Context required for voice input and clipboard on non-localhost origins.

APP_HOST=0.0.0.0
APP_SSL_CERTFILE=.certs/cert.pem
APP_SSL_KEYFILE=.certs/key.pem

Setup with mkcert:

  1. Install mkcert and run mkcert -install
  2. Issue a certificate: mkcert -cert-file .certs/cert.pem -key-file .certs/key.pem <your-ip> localhost 127.0.0.1
  3. Set the env vars above in .env
  4. Allow the ports through your firewall (8000 production, 5173 dev)
  5. Install the CA certificate (rootCA.pem) on each client device

Access from the LAN at https://<your-ip>:8000. When SSL is not configured, the server runs in HTTP mode as usual (no breaking change).

Corporate networks (TLS-intercepting proxy)​

Behind a corporate proxy (Zscaler, Netskope, on-prem SSL middlebox), the first outbound HTTPS call can fail because Python's bundled certifi store does not know your in-house root CA:

httpx.ConnectError: [SSL: CERTIFICATE_VERIFY_FAILED]
certificate verify failed: self-signed certificate in certificate chain

The recommended remedy is the opt-in corp extras, which route TLS validation through the host OS certificate store:

pip install "chatwalaau[corp]"

No source change, no env change, and no behavior change for non-corporate environments. Alternatively, point Python at an explicit CA bundle:

export SSL_CERT_FILE=/path/to/corp-root-ca.pem
export REQUESTS_CA_BUNDLE=/path/to/corp-root-ca.pem
DevUI has been removed

Up to 0.163.0 the backend could start the Microsoft Agent Framework DevUI on a second port with the DEVUI_* settings. 0.164.0 removes it. The debug agent it served never matched the one the product runs -- it was built without MCP tools and without rag_search, so what you saw there was not what your chat does -- and its capabilities are covered by the chat itself, the OpenAI-compatible API, workflows, harness agents and the usage dashboard. DEVUI_* keys left in an existing .env are ignored, so nothing breaks; you can delete them when convenient.

Prompt dump (what the model actually received)​

When an answer is wrong and the configuration looks right, the useful question is what the model was actually sent. Enable the prompt dump:

PROMPT_DUMP_ENABLED=true
# PROMPT_DUMP_DIR=.prompts # default

Each run writes a timestamped Markdown file containing the assembled system prompt (first turn only -- it is frozen for the session), the flowing conversation, and the tool surface. Prompt content goes only to the file; the logs carry metadata.

In the system prompt, each tool's usage guidance is grouped into its own labeled <tool-guide name="weather">, <tool-guide name="rag">, ... block, so you can see at a glance which instructions belong to which tool.

Turn it off when you are done: the files accumulate and contain your conversations.

Tool surface​

The tool surface section lists every built-in function, every MCP server and tool, and every Skill -- including the ones that are not there, with the reason:

### Built-in functions (4 active / 13 excluded)

- file_write ACTIVE
- bash_execute EXCLUDED allowlist
- rag_search EXCLUDED settings (CHROMA_DIR unset or no embeddings offering)
- manage_cron EXCLUDED settings (CRON_ENABLED=false)

### MCP (1 active server / 1 excluded / 1 warning)

- github ACTIVE 2/14 tools
- create_issue ACTIVE
- delete_repo EXCLUDED mcp override
- filesystem EXCLUDED allowlist (server not selected)
- slack WARNING not connected; allow-list not applied

Each reason points at the surface that owns the gate:

ReasonWhere to fix it
settingsyour .env -- the row names the variable or the missing model offering
allowlistthe Declarative Agent editor's tool selection
mcp overridethe MCP Servers screen (disabled there)
skills overridethe Skills Manager
not connectedthe MCP server is configured but not connected; Reload once it is up

A MISMATCH row means the built agent and your configuration disagree with no explanation -- the tool should have been there and is not, or the reverse. That is a defect, not a setting; capture the dump and report it.

A WARNING not connected row matters for a different reason: while a server is unconnected its tool names are unknown, so a per-tool allow-list cannot be applied and every tool of that server is exposed once it connects.

The section is written on every turn (unlike the system prompt) because tool state can change mid-session -- from the MCP manager, the Skills manager, or by switching Declarative Agent. The digest line shows at a glance which turn it changed on.

A chat reply ends with "network error"​

Error: network error in a chat reply is the browser's message for a response that was cut while it was streaming; the server did not report an error. Behind Azure App Service or Azure Container Apps, the usual cause is the front end's idle limit: it closes a connection that carried no data for about four minutes.

  • Since v0.197.1 every chat turn sends an SSE comment (: keep-alive) after each 15 seconds without output, so a turn that is busy but silent -- a slow tool, a web search, a long reasoning pass -- is not cut. If you put another proxy in front of ChatWalaʻau, make sure it does not buffer text/event-stream responses (the server already sends X-Accel-Buffering: no and Cache-Control: no-cache).

  • When the browser closes a chat stream before the reply finished, the server logs one warning:

    AG-UI stream closed by the client before the run ended: thread=<id> run=<id>
    lane=prompt elapsed=231.4s silent_for=3.2s keepalives=14

    silent_for is the time since the last real event. A value near four minutes with keepalives=0 means the keep-alives did not reach the browser (a buffering hop). A small value means the user pressed Stop, reloaded, closed the tab or changed network. The line never contains message text.

  • The user sees the text that arrived, a notice that the reply was not saved, and a Retry (see Message actions).