Transport policy в OpenClaw 2026.9.8: правки без отзыва ран

Коротко

В 2026.9.8 правки transport policy (заголовки прокси, OIDC-сопоставление, авто-одобрение устройств, адреса доверенных прокси) требуют переподключения клиентов, но сохраняют принятые раны и очередь входов с неизменными грантами.
Правка identity-scope по-прежнему отзывает принятые раны и очередь входов безвозвратно, если изменён грант самой затронутой идентичности. Восстановление гранта не возвращает отозванную работу.
HTTP-запросы и cookie плагинов используют собственные пути и под identity-scope не попадают: для них правка грантов проходит незаметно.

Сверено с документацией OpenClaw 2026.9.8, 3 октября 2026.

Раньше правки gateway.auth.identityScopes и gateway.auth.trustedProxy рвали операторские WebSocket-соединения, чей собственный разрешённый грант менялся. В 2026.9.8 эти правки разделили на две корзины. Правки transport policy (заголовки прокси, OIDC-сопоставление, адреса доверенных прокси, авто-одобрение устройств) переподключают клиентов, но не трогают уже принятую работу с неизменными грантами. Правки, которые меняют грант самой подключённой идентичности, по-прежнему отзывают её раны. Это разделение видно в сравнении версий страницы trusted-proxy auth.

Что изменилось в 2026.9.8

Документация по trusted proxy auth явно разводит два класса правок. Transport policy описывает, как прокси передаёт идентичность и какие адреса считать доверенными. Сюда входят userHeader, requiredHeaders, allowLoopback, trustedProxies, deviceAutoApprove и OIDC-сопоставление. Identity-scope — это содержимое gateway.auth.identityScopes и решение о членстве в allowUsers.

Смена transport policy теперь требует переподключения клиентов. Сохраняются принятые раны и очередь входов, чьи гранты доступа не изменились. Снятие подключённой идентичности из allowUsers, отключение её метода аутентификации или правка её собственного гранта identity-scope по-прежнему отзывают её принятую работу. Восстановление гранта отозванную работу не возвращает.

Конфиг trusted-proxy auth

Базовый блок для правок, которые теперь не рвут раны:

{
  gateway: {
    bind: "lan",
    trustedProxies: ["10.0.0.1", "172.17.0.1"],
    auth: {
      mode: "trusted-proxy",
      identityScopes: {
        "admin@company.org": ["operator.admin"],
      },
      trustedProxy: {
        userHeader: "x-forwarded-user",
        requiredHeaders: ["x-forwarded-proto", "x-forwarded-host"],
        allowUsers: ["nick@example.com", "admin@company.org"],
        allowLoopback: false,
        deviceAutoApprove: {
          enabled: false,
          scopes: ["operator.read", "operator.write", "operator.approvals", "operator.questions"],
        },
      },
    },
  },
}

Сюда входят userHeader, requiredHeaders, trustedProxies и блок deviceAutoApprove. Членство в allowUsers и identityScopes это уже identity-scope, и там поведение прежнее.

Как проверить, что заработало

Откройте Control UI под оператором с операторским грантом и запустите длинную рану, например ресёрч по репозиторию.
Поменяйте userHeader на новое имя заголовка и сохраните конфиг.
Проверьте, что Control UI показывает исходную рану как выполняющуюся, а не откатил её к ошибке. Поставьте сообщение в очередь: оно должно прийти в работу после переподключения.
Снимите оператора из allowUsers и сохраните. В той же ране Control UI должен оборвать соединение и отозвать рану. Верните оператора в список, и рана не вернётся.

Где ломается и когда не применять

HTTP-запросы к Gateway и cookie плагинов используют отдельные пути аутентификации и не работают через гранты identity-scope. Для них правка грантов проходит незаметно.

Применять приём стоит только там, где есть операторы с постоянным грантом identity-scope и длительными ранами. Если оператор подключается только чтобы отправить короткий запрос и уйти, переподключение после правки ничего не стоит. Не применяйте приём к правкам, которые явно задевают allowUsers, identityScopes или метод аутентификации самого клиента, там отзыв ран останется безвозвратным, как и раньше.