fix(waker): credenziale password + client backend per chat.send, sourceTool visibile #17

Merged

claudia merged 1 commit from fix/wake-chatsend-auth into main 2026-09-14 16:12:32 +00:00

Conversation 0 Commits 1 Files changed 5 +132 -54

claudia commented 2026-09-14 16:12:24 +00:00

Owner

Copy link

Il connect chatsend introdotto dalla #16 veniva rifiutato dal Gateway OpenClaw con NOT_PAIRED / device identity required. Due cause, entrambe verificate sui sorgenti OpenClaw 2026.8.x e contro il gateway vivo in loopback.

1. Identita' del client sbagliata. client.id/client.mode non sono stringhe libere: OpenClaw li valida su enum chiusi (GATEWAY_CLIENT_IDS/GATEWAY_CLIENT_MODES). Ma soprattutto e' su gateway-client + backend che aggancia shouldSkipLocalBackendSelfPairing: l'unico percorso che, senza device identity registrata, preserva gli scope richiesti. Tutte le altre combinazioni passano da shouldClearUnboundScopesForMissingDeviceIdentity, che azzera gli scope — e senza operator.admin i campi di provenance vengono rifiutati, quindi l'esito tornerebbe comunque attribuito all'utente.

2. Il token non e' una credenziale valida qui. Il nostro OpenClaw e' in auth mode trusted-proxy, dove il fallback a token e' disattivato per scelta (docs/gateway/trusted-proxy-auth.md: "Token fallback remains intentionally unsupported in trusted-proxy mode"). Gli header di identita' del proxy non valgono da loopback (fail closed, voluto). La credenziale per i client interni che non passano da nginx e' gateway.auth.password / OPENCLAW_GATEWAY_PASSWORD → nuovo GW_WAKE_WS_PASSWORD, inviato come auth.password nel connect. GW_WAKE_WS_TOKEN resta per le istanze in auth mode token.

3. sourceTool di default → soltea_agent_runner. Fuori dalla lista dei source tool da completion report: l'esito del runner resta visibile in chat (marcato inter-sessione, non turno dell'utente) finche' teniamo il meccanismo sotto osservazione. Con agent_harness_task sparirebbe dalla cronologia proiettata.

Suite: 96 passed.

Il connect `chatsend` introdotto dalla #16 veniva **rifiutato** dal Gateway OpenClaw con `NOT_PAIRED` / `device identity required`. Due cause, entrambe verificate sui sorgenti OpenClaw 2026.8.x e contro il gateway vivo in loopback. **1. Identita' del client sbagliata.** `client.id`/`client.mode` non sono stringhe libere: OpenClaw li valida su enum chiusi (`GATEWAY_CLIENT_IDS`/`GATEWAY_CLIENT_MODES`). Ma soprattutto e' su `gateway-client` + `backend` che aggancia `shouldSkipLocalBackendSelfPairing`: l'unico percorso che, senza device identity registrata, **preserva gli scope richiesti**. Tutte le altre combinazioni passano da `shouldClearUnboundScopesForMissingDeviceIdentity`, che azzera gli scope — e senza `operator.admin` i campi di provenance vengono rifiutati, quindi l'esito tornerebbe comunque attribuito all'utente. **2. Il token non e' una credenziale valida qui.** Il nostro OpenClaw e' in auth mode `trusted-proxy`, dove il fallback a token e' disattivato per scelta (`docs/gateway/trusted-proxy-auth.md`: *"Token fallback remains intentionally unsupported in trusted-proxy mode"*). Gli header di identita' del proxy non valgono da loopback (fail closed, voluto). La credenziale per i client interni che non passano da nginx e' `gateway.auth.password` / `OPENCLAW_GATEWAY_PASSWORD` → nuovo `GW_WAKE_WS_PASSWORD`, inviato come `auth.password` nel connect. `GW_WAKE_WS_TOKEN` resta per le istanze in auth mode `token`. **3. `sourceTool` di default → `soltea_agent_runner`.** Fuori dalla lista dei source tool da *completion report*: l'esito del runner resta **visibile** in chat (marcato inter-sessione, non turno dell'utente) finche' teniamo il meccanismo sotto osservazione. Con `agent_harness_task` sparirebbe dalla cronologia proiettata. Suite: **96 passed**.

claudia added 1 commit 2026-09-14 16:12:25 +00:00

fix(waker): credenziale password + client backend per chat.send, sourceTool visibile ... 6c92eedbdd

Il connect chatsend veniva rifiutato dal Gateway OpenClaw con NOT_PAIRED
"device identity required": client.id/mode non erano valori degli enum
GATEWAY_CLIENT_IDS/MODES e il token non e' una credenziale valida in auth
mode trusted-proxy.

- client `gateway-client`/`backend` da loopback: e' l'unica coppia che fa
  scattare shouldSkipLocalBackendSelfPairing, che salta la device identity
  E preserva gli scope richiesti (le altre li azzerano, e senza
  operator.admin la provenance viene rifiutata).
- nuovo GW_WAKE_WS_PASSWORD (gateway.auth.password): in trusted-proxy il
  fallback a token e' disattivato per scelta di OpenClaw e gli header di
  identita' del proxy non valgono da loopback. GW_WAKE_WS_TOKEN resta per
  le istanze in auth mode token.
- default GW_WAKE_SOURCE_TOOL: soltea_agent_runner (fuori dai source tool
  da completion report) cosi' l'esito del runner resta VISIBILE in chat
  finche' teniamo il meccanismo sotto osservazione.

Suite: 96 passed.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

claudia merged commit 35ff20090a into main 2026-09-14 16:12:32 +00:00

claudia referenced this pull request from a commit 2026-09-14 16:12:34 +00:00

Merge pull request 'fix(waker): credenziale password + client backend per chat.send' (#17) from fix/wake-chatsend-auth into main

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

Soltea-org/soltea-agent-gateway!17

No description provided.