Иногда AI-агент в OpenClaw ведет себя как очень вежливый, но слегка тревожный сотрудник.
Ты ему уже выдал пропуск, ключи от серверной и доступ к шкафу с инструментами, а он все равно смотрит в глаза и говорит:
“Кажется, у меня нет полных прав”.
Знакомо? У меня как раз был такой кейс.
Я настраивал OpenClaw-агента в Telegram, дал ему расширенные права, разрешил выполнять команды, работать с файлами вне workspace, подключил нужную модель, а агент все равно периодически отвечал, что elevated-доступа у него нет.
На первый взгляд кажется, что система “сломалась”. На самом деле чаще всего проблема не в правах как таковых, а в сочетании из трех вещей:
- права выданы, но не на тот контекст
- живая сессия помнит старые ограничения
- агент сам делает неверную проверку и путает ошибку команды с отсутствием доступа
То есть не “катастрофа”, а классическая история из мира автоматизации: доступ есть, но кто-то читает не тот бейджик.
В чем была проблема
В моем случае агент работал через Telegram в OpenClaw.
Я включил ему расширенные права, но в одной из старых direct-сессий он продолжал считать, что elevated ему недоступен.
Плюс сверху был еще один веселый нюанс: агент проверял ClawHub командой:
```bash
clawhub --version
```
А у `clawhub` такой флаг вообще невалидный.
Правильные варианты:
```bash
clawhub -V
```
или
```bash
clawhub --cli-version
```
В итоге происходило следующее:
- агент запускал неверную команду
- команда падала
- агент делал вывод: “у меня, наверное, нет прав”
- хотя на самом деле у него были права, а не было только правильного флага
То есть виноват был не OpenClaw, не Telegram и не “злой сервер”, а старая добрая комбинация из контекста, кэша сессии и человеческого фактора. Только фактор уже не человеческий, а агентский.
Как понять, что проблема именно в этом
Если агент жалуется на неполный доступ, а вы уже включали расширенные права, проверьте три вещи.
1. Включен ли elevated глобально
Нужно убедиться, что в конфиге OpenClaw есть примерно такая логика:
```json
"tools": {
"elevated": {
"enabled": true,
"allowFrom": {
"telegram": ["ВАШ_TELEGRAM_ID"]
}
}
}
```
Ключевой момент здесь не просто `enabled: true`, а именно `allowFrom.telegram`.
Если этого нет, direct-чат из Telegram может не проходить gate проверки, и агент будет получать отказ даже при внешне “правильной” конфигурации.
2. Какие реальные exec-права действуют
Дальше смотрим `tools.exec`:
```json
"tools": {
"exec": {
"host": "auto",
"security": "full",
"ask": "off"
}
}
```
Если вы хотите, чтобы агент действительно мог сам ставить пакеты, править конфиги и выполнять системные команды, effective policy должна быть именно такой:
- `security=full`
- `ask=off`
Если там allowlist или ручные approvals, агент может воспринимать это как “доступ не полный”.
3. Ограничен ли доступ к файловой системе только workspace
Еще один важный пункт:
```json
"tools": {
"fs": {
"workspaceOnly": false
}
}
```
Если оставить `workspaceOnly: true`, агент сможет работать только внутри своей песочницы.
Иногда этого достаточно, но если задача связана с системными файлами, сервисами, конфигами OpenClaw или установкой пакетов, он снова будет ощущать себя как кот перед закрытой дверью: видит цель, но не может пройти.
Почему проблема может остаться даже после выдачи прав
Вот это самая интересная часть.
Даже если вы все уже настроили правильно, старая Telegram-сессия может продолжать жить со старыми override-параметрами.
То есть глобально права и модель уже новые, а конкретный чат все еще помнит старую маршрутизацию.
В моем случае пришлось отдельно проверить session store и убедиться, что Telegram direct-сессия действительно идет через нужную модель и нужный провайдер, а не живет на старом fallback.
Для Telegram-сессии это выглядело как явная фиксация:
- `providerOverride = openai-codex`
- `modelOverride = gpt-5.4`
- `authProfileOverride = openai-codex:...`
Если этого не сделать, агент может стартовать сообщение через старую схему, а потом уже переключаться по fallback.
Снаружи это выглядит хаотично: то он умный и уверенный, то снова “ой, кажется, у меня нет доступа”.
Что нужно сделать, чтобы решить проблему
Вот нормальный рабочий порядок.
Шаг 1. Включить elevated именно для Telegram
Не “для всех подряд”, а для доверенного пользователя.
Примерно так:
```json
"tools": {
"elevated": {
"enabled": true,
"allowFrom": {
"telegram": ["3..............1"]
}
}
}
```
Так безопаснее и понятнее.
Шаг 2. Включить полный exec-режим
```json
"tools": {
"exec": {
"host": "auto",
"security": "full",
"ask": "off"
}
}
```
Это дает агенту реальную возможность выполнять команды без ручного подтверждения на каждом шаге.
### Шаг 3. Убрать ограничение только на workspace, если нужны системные действия
```json
"tools": {
"fs": {
"workspaceOnly": false
}
}
```
Шаг 4. Проверить effective policy, а не только конфиг
Это важно.
Потому что “в файле красиво написано” и “реально применяется” иногда две разные вселенные.
Нужно смотреть именно effective state:
- включен ли elevated
- какой реальный exec policy применяется
- не режет ли host approvals итоговый доступ
Шаг 5. Зафиксировать модель для Telegram-сессии
Если у вас основной агент должен идти через `openai-codex/gpt-5.4`, лучше явно закрепить это для Telegram direct и slash-сессий.
Иначе часть запросов может улетать в fallback-маршрут, а потом агент будет отвечать в разном стиле и с разной уверенностью в собственных возможностях.
Шаг 6. Записать агенту подсказку в рабочие инструкции
Это недооцененный, но очень полезный пункт.
Я обычно добавляю такие вещи в `TOOLS.md` или локальные инструкции workspace.
Например:
- у тебя есть elevated-доступ в direct Telegram-чате
- `tools.exec` работает в режиме `security=full`, `ask=off`
- `tools.fs.workspaceOnly=false`
- для проверки версии `clawhub` используй `-V` или `--cli-version`
- не делай вывод об отсутствии прав только потому, что упала неверная команда
Это помогает убрать странные ложные сомнения у агента.
Короткий вывод
Если OpenClaw-агент говорит, что у него “неполный доступ”, это не всегда значит, что права реально не выданы.
Чаще всего причина одна из этих:
- не настроен `allowFrom` для Telegram
- старая сессия живет со старым контекстом
- модель или провайдер в чате идут не туда
- агент проверяет доступ неправильной командой
- в инструкциях ему не объяснено, что доступ уже есть
То есть проблема обычно не мистическая, а инженерная.
Без магии, зато с логами.
И это, кстати, хорошая новость.
Потому что инженерные проблемы решаются.
В отличие от некоторых “экспертов”, которые до сих пор рассказывают, что AI-агенты заменят всех уже к пятнице.