RU
EnglishРусскийEspañol
Bitrix24

История изменений

История выпусков CLI Битрикс24: новые возможности, изменения и исправления.

Заметные изменения в @wirecat/bitrix24-cli. По одному разделу на версию, новые сверху.

0.14.0 — 12.11.2026

Добавлено

  • b24 guide показывает сценарии для частых задач: команды по порядку и зачем каждая. first-sync (первая синхронизация и доска воронки), keep-in-sync (таймер и поиск) и safe-agent-writes (агент через MCP, чьи записи остаются под вашим контролем). b24 guide <name> --json выдает один сценарий как данные.
  • Страницы MCP и Разрешения. Как подключить b24 к агенту, что агент видит и чего ему никогда не предлагают. Каждый уровень, встроенные уровни, ключи, которые проверяет одна команда, и проверки, которые не снимает ни один уровень.
  • Вход через локальное приложение. b24 <profile> session start --portal <host> --client-id <id> входит через локальное приложение, которое вы создаете на портале, в браузере и действует с правами сотрудника, который вошел. Ключ приложения спрашивается скрытым вводом или читается из stdin или B24_BITRIX24_CLIENT_SECRET. Вход возвращается через https://wirecat.dev/webhooks/apps/b24-callback или через адрес, который вы вставите. Токены обновляются сами. session status и session list показывают способ входа, а session end забывает любой из них. Входящий вебхук остается быстрым способом, см. вход.

Исправлено

  • Быстрый старт копирует сделки. В README теперь до первого sync выбирается, чьи сделки и лиды копировать, а до этого он ничего не копирует. README больше не говорит, что администратор копирует всю CRM, говорит, что через MCP удаление с уровнем ask выполняется, и называет wcat-b24 на случай, если первой находится команда b24 из другого пакета. В устранении неполадок есть ошибка "no CRM user is chosen".
  • Через MCP ask не останавливает запись. README, безопасность и первый экран советовали ставить deals.move на ask против роботов портала. Но так перемещение останавливается только в терминале: через MCP отвечать некому, и запись проходит. Теперь там сказано ставить readonly или deny или включить подтверждение в клиенте агента.
  • Навык агента покрывает то, что агенту нужно. В b24 skill show теперь есть коды выхода и причины ошибок, MCP и ловушка с ask, первая настройка от вебхука до первой синхронизации, границы записи и подводные камни.
  • В примерах везде профиль work вместо personal.
  • b24 commands показывает CRM по разделам. Сделки, лиды, контакты и компании разделены на Read и Write, воронки, стадии, поля, товары, пользователи и api стоят в Read, sync в Automate, а session в Set up. Раньше большая часть b24 была в Other.
  • Два локальных файла состояния пишутся атомарно и остаются закрытыми. Список ваших собственных компаний и дневной счетчик показанных чужих клиентов теперь пишутся через временный файл и переименование, как и файл настроек.
  • Ежедневный sync больше не читает всех клиентов заново. Раунд изменений читал каждый контакт и каждую компанию из сделок и лидов выбранных пользователей, даже если ничего не менялось. На портале с 50 000 сделок это было около 300 запросов и почти три минуты на синхронизацию без новых данных. Теперь он читает только клиентов изменившихся сделок и лидов, а сделки пользователей для их клиентов получает один раз за синхронизацию, а не отдельно для контактов и для компаний.

0.13.0 — 11.11.2026

Изменено — может сломать вызовы

  • Удаляет и очищает в CRM только вебхук администратора Битрикс24. Для любого другого вебхука b24 отклоняет deals delete, leads delete, api call к методу, который удаляет (его имя заканчивается на .delete, .deletefieldvalue или .markdeleted), обновление или .set, которое делает поле пустым (пустое значение, null, [], связь с компанией, контактом или лидом 0, телефон или e-mail с пометкой DELETE: Y), а также batch. Отказ приходит как permission_error с причиной employee.delete, employee.clear или employee.batch, и ни один уровень разрешений его не снимает. При создании поля по-прежнему можно оставить пустыми.
  • Отвязывает записи и объединяет дубли только вебхук администратора Битрикс24. Для любого другого вебхука api call отклоняет метод, имя которого заканчивается на .unbind, например crm.timeline.bindings.unbind, с причиной employee.unbind, и объединение дублей crm.entity.mergeBatch, которое удаляет все записи, кроме одной, с причиной employee.merge. Как и для удалений, ни один уровень разрешений этого не снимает. crm.deal.contact.delete и crm.deal.contact.items.delete и раньше считались удалениями.
  • Аккаунт портала хранится как рабочий. Первый sync, запись или чтение в профиле сохраняет аккаунт нового портала с областью work, поэтому рабочие представления и подготовка к встречам читают его копию, а личные чтения ее пропускают. Портал, который уже есть в хранилище, сохраняет свою область, а во всех хранилищах до сих пор это personal. Переключите ее один раз командой memo groups update bitrix24:<portal> --scope work (memo 0.131.81 или новее). Синхронизация никогда не меняет область обратно.

0.12.0 — 10.11.2026

Добавлено

  • store apply убирает из копии, сделанной при scope mine, контакты, которые не названы ни в одной сделке или лиде выбранных пользователей и не относятся ни к одной оставленной компании, а также людей, которые после этого остаются пустыми. Без --yes команда только считает. Синхронизация, которая сужает копию, или sync --rescan делают это сами, и в их ответе количество приходит как contacts_removed.
  • Основан на cli-core 0.631.0 (было 0.630.0). При первом открытии хранилище переходит на версию 64: сохранение или удаление связи сделки с человеком больше не читает все такие связи. Что изменилось, описано в истории изменений cli-core.

Изменено — может сломать вызовы

  • Синхронизация копирует только сделки и лиды пользователей, которых владелец выбрал в crm.bitrix24:<portal>.unassigned, и их клиентов. По умолчанию не выбран никто, даже пользователь самого вебхука. Пока владелец не выберет, синхронизация отклоняется (configuration_error, причина bitrix.scope-users-unchosen) и называет config set, который нужно выполнить. Обратите внимание, что существующая копия упадет при следующей синхронизации, пока владелец не выберет пользователей.
  • Ни одна синхронизация больше не копирует всю CRM, даже у администратора. Синхронизация при сохраненном scope all отклоняется (причина bitrix.scope-all-refused, было bitrix.scope-all-admin-only) и предлагает поставить mine. После этого сделки и лиды невыбранных пользователей помечаются удаленными в локальной копии. Любого другого клиента можно найти на портале напрямую через people list или organizations list.
  • Вебхук сотрудника может выбрать себя, уволенного пользователя или не сотрудника, а вебхук администратора кого угодно.

Исправлено

  • Имя контакта больше не несет null или null #<id>, которые импорт в портал оставил в полях имени ("Ярослав Орлов null #907" теперь "Ярослав Орлов"). На одном живом портале так было у 101 876 из 114 165 контактов. Обратите внимание, что имя, сохраненное раньше, сохраняет этот хвост, пока контакт не синхронизируется снова.
  • Основан на cli-core 0.630.0 (было 0.623.0). При первом открытии хранилище переходит на версию 63. Контакт CRM больше не присоединяется к вашему собственному человеку и не переименовывает его, а два контакта с общим ящиком или телефоном компании остаются двумя людьми. Что изменилось за это время, описано в истории изменений cli-core.

0.11.0 — 10.11.2026

Изменено — может сломать вызовы

  • При scope mine синхронизация копирует только клиентов пользователя: контакты и компании, назначенные ему или пользователю из списка ничьих, и те, что названы в копируемых сделках и лидах. Раньше она копировала всю базу контактов и компаний портала, 114 165 контактов на одном живом портале, где у пользователя не было ни одной сделки. Ежедневный проход по удалениям тоже перечисляет только эти id. Обратите внимание, что копия, в которой уже есть вся база, сохраняет свои контакты, а компании ждут sync --rescan.
  • Синхронизировать при scope all может только администратор Битрикс24. Руководителю отдела отказывают так же, как сотруднику (bitrix.scope-all-admin-only, было bitrix.scope-all-manager-only).
  • Все, кроме администратора Битрикс24, видят телефоны и e-mail только своих клиентов. people list и organizations list не показывают их у остальных, а people show и organizations show для одной записи показывают, но не больше 100 таких контактов и компаний в день на пользователя и его агентов вместе. api call отклоняет чтение контактов и компаний (crm.contact.*, crm.company.*, crm.item.* типа 3 или 4, реквизиты, адреса, поиск дублей) для всех, кроме администратора, что бы ни говорили разрешения.
  • Назвать работающего сотрудника в crm.bitrix24:<portal>.unassigned может только администратор Битрикс24. Руководитель отдела, как и все остальные, может назвать только уволенных пользователей и не сотрудников.
  • Основан на cli-core 0.623.0 (было 0.621.0). При первом открытии хранилище переходит на версию 61 (связи между людьми, только добавления). Что изменилось за это время, описано в истории изменений cli-core.

0.10.0 — 09.11.2026

Добавлено

  • session start и session status --check отвечают рядом с admin, manager ли пользователь вебхука, то есть администратор Битрикс24 или руководитель отдела.

Изменено — может сломать вызовы

  • Все сделки и лиды копирует только руководитель: синхронизация при crm.bitrix24:<portal>.scope all отклоняется (configuration_error), если пользователь вебхука не администратор Битрикс24 и не руководитель отдела. Это проверяется при каждой синхронизации. Все остальные копируют свои сделки и лиды и ничьи, а отказ советует поставить scope в mine. Обратите внимание, что без области department у вебхука руководитель отдела считается сотрудником.
  • Для всех, кроме руководителя, crm.bitrix24:<portal>.unassigned учитывает только пользователей, которых портал показывает уволенными или не сотрудниками (экстранет, e-mail, бот), и это проверяется при каждой синхронизации. Работающий сотрудник в списке пропускается с причиной в issues синхронизации (crm.unassigned-dropped), а его сделки и лиды уходят из локальной копии. Руководитель по-прежнему может указать кого угодно. Обратите внимание, что без области user у вебхука для сотрудника ничьим не считается никто.

0.9.0 — 09.11.2026

Добавлено

  • sync хранит в локальном хранилище, кто есть кто. Контакт состоит в каждой своей компании с ролью contact, и рядом стоит его должность. У сделки и лида есть их контакты с отметкой главного, а ответственный за них стоит как owner. Сотрудники состоят в ваших собственных компаниях, читаются при каждой синхронизации и подчиняются руководителю своего отдела. Сконвертированный лид указывает на свою сделку. Эти связи остаются reported, пока вы их не подтвердите, завершаются, а не удаляются, когда портал перестает о них говорить, и никогда не меняют связь, которую создали вы. Обратите внимание, что вебхуку нужны области user_basic и department для e-mail сотрудников и подчинения. Без них синхронизация читает все остальное.
  • schedule ставит таймер, который сам запускает sync или другую команду b24. MCP ее не предлагает.
  • По умолчанию синхронизация копирует только сделки и лиды собственного пользователя вебхука и пользователей из crm.bitrix24:<portal>.unassigned. Битрикс24 всегда называет ответственного, поэтому так сделки из формы на сайте или из интеграции считаются ничьими. config set crm.bitrix24:<portal>.scope all копирует все. В ответе синхронизации есть scope (с пользователем вебхука как self) и out_of_scope для каждого вида записей: сделка, переданная другому пользователю, уходит из локальной копии при следующей синхронизации. Контакты и компании, как и раньше, копируются целиком.
  • Если настройки scope нет, первый mine, который пометил бы удаленными больше половины сохраненных сделок или лидов, оставляет их (crm.narrowing-held), пока владелец не задаст scope. Агент не может задать scope, self или unassigned.
  • Копия одного портала принадлежит одному пользователю. Синхронизация через вебхук другого пользователя, чем при первой синхронизации, отклоняется до config unset crm.bitrix24:<portal>.self.

Изменено — может сломать вызовы

  • В people сделки и лида теперь есть ответственный сотрудник с ролью owner рядом с ее контактами. Обратите внимание на код, который считал каждую запись в people контактом клиента.
  • store status считает ваши собственные компании среди организаций, а сотрудников портала среди людей.
  • api call department.get и crm.mycompany.basic.list выполняются без вопроса, как и другие чтения, которые делает b24. department.get отклоняется при users.list: deny, а crm.mycompany.* при organizations.list: deny.
  • Вебхук, созданный только с областями crm и user, теперь получает запись в issues при каждой синхронизации: Битрикс24 не отдает ему отделы. Добавьте область department или будьте готовы к этой записи.
  • Первая синхронизация после обновления помечает удаленными в локальной копии сделки и лиды других пользователей. Они пропадают из списков и поиска, а их прежняя копия остается в файле хранилища. Чтобы сохранить их, задайте crm.bitrix24:<portal>.scope all до нее.
  • Ответ списка без элементов теперь проваливает синхронизацию этого вида записей (invalid_response), а не заканчивает на нем список.

Исправлено

  • api show department.get и api call называли область метода basic, а у Битрикс24 это department.
  • Метод, который Битрикс24 разрешает вызывать только установленному приложению (WRONG_AUTH_TYPE), отклоняется как permission_error с причиной webhook.app-only. Раньше b24 говорил, что вебхук отклонен, и просил войти снова, а это не поможет. Обратите внимание на скрипты, которые ветвились по authentication_error для этого отказа.
  • create и update для people и organizations объявляют свои ответы (crm_record_created, crm_record_updated), поэтому --json принимает их поля, а commands info их перечисляет.
  • session start и устранение неполадок называют те же области вебхука, что и README: crm, user_basic и department. Устранение неполадок еще просило catalog, который b24 не использует.
  • api show, api list и отказ при вызове называли область basic для каждого метода вне пяти префиксов имен, например im.message.add и tasks.task.add. Теперь они называют область из справочника Битрикс24 (im, task, calendar) или unknown, а отказ для неизвестной области не называет никакой.

Безопасность

  • b24 отправляет запросы только на портал из адреса вашего вебхука и отклоняет любой другой хост до того, как с машины уйдет хоть один байт. Его манифест говорит об этом (network), поэтому WireCat Desktop показывает, куда уходят данные.

0.8.0 — 08.11.2026

Добавлено

  • Пакет поставляет contracts/wirecat.json, поэтому WireCat Desktop до установки может прочитать, что делает b24, как войти и что копирует sync. b24 --wcat-describe теперь отвечает в формате 2: раздел Desktop из этого файла и его SHA-256.

Исправлено

  • Первая синхронизация большого портала занимает гораздо меньше памяти и идет на треть быстрее: на синтетических данных с 20 000 сделок пик падает с 3,7 ГБ до 0,55 ГБ.
  • session start снова спрашивает вебхук, если ничего не пришло. Пустой Enter в скрытом вводе, например после Ctrl+V, который ничего не вставил в терминале Linux, сразу заканчивался ошибкой "no webhook address was given". Теперь команда подсказывает вставить через Ctrl+Shift+V (Cmd+V на macOS) и спрашивает снова, до трех раз.
  • Сбой при запуске b24 или в ожидаемом шаге завершается с кодом 1 и ошибкой сбоя b24 (command.crashed в JSON, когда stdout не терминал). Раньше печатался сырой стек Node.

0.7.0 — 08.11.2026

Добавлено

  • Пакет ставит команду еще и как wcat-b24, поэтому wcat b24 ее запускает, а wcat --help показывает в списке. b24 --wcat-describe печатает, что это за инструмент, его версию и страницу документации.
  • config set owner_languages задает языки, на которых читает владелец.

Изменено — может сломать вызовы

  • Поиск без единой буквы или цифры отклоняется (validation_error). "", одинокий ? или один эмодзи ничего не находили и ничего не сообщали. Одинокий * по-прежнему читается как подстановочный знак.

Исправлено

  • Первая синхронизация большого портала идет примерно вдвое быстрее. Она больше не замедляется с каждой сохраненной сделкой: на синтетических данных с 10 ответственными за сделки 20 000 сделок, 10 000 лидов и 20 000 контактов синхронизируются за 30 с вместо 61 с.

0.6.0 — 08.11.2026

Добавлено

  • people list --format csv и organizations list --format csv печатают страницу как таблицу CSV для электронной таблицы, как теперь и deals list с leads list. В stdout идет только таблица; путь к следующей странице идет в stderr. Столбцы — собственные поля записи, затем каждое пользовательское поле портала по его названию: денежное поле как <label> amount и <label> currency, а два поля с одним названием различаются по коду. --json=a,b рядом выбирает столбцы, пользовательское поле — как provider_metadata.<code>. Ячейка, с которой электронная таблица начала бы формулу, получает в начале '. --jsonl, --json без полей и --compact отклоняются с output.conflict, а агентам этот параметр не дается.
  • pipelines show — доска воронки продаж: для каждой стадии ее сделки или лиды и их сумма в каждой валюте, а в терминале — таблица стадий с суммой открытых, числом выигранных и проигранных и долей выигранных. Воронку можно не называть, если на портале она одна.

Изменено — может сломать вызовы

  • Пользовательское поле, которого на портале нет, названное в запросе списка или в --json, отклоняется с param --query или --json, а не --field.
  • Команда для профиля без вебхука отклоняется с причиной session.missing, а не webhook.missing: это единый ответ «не выполнен вход», который дает каждый инструмент WireCat с API-токеном. Вебхук читается и хранится там же, где раньше: B24_TOKEN, затем запись token:<profile> в связке ключей под bitrix24-cli, затем закрытый файл; теперь это делает общее хранилище токенов cli-core.

0.5.0 — 07.11.2026

Добавлено

  • sync копирует воронки, компании, контакты, сделки и лиды портала в локальное хранилище WireCat: то, что изменилось с прошлой синхронизации, или все с --rescan; раз в день он также находит, что портал удалил. store status показывает, насколько продвинулся каждый вид. Синхронизация останавливается до своего срока или --max-pages, а следующая продолжает с этого места.
  • deals close <ref> won|lost и leads close, на первую стадию успеха или провала воронки записи, а также deals delete и leads delete, которые сначала спрашивают.
  • deals create и update принимают --pipeline, --stage, --amount с --currency, --close-date и --owner; лиды принимают то же, кроме --close-date. Стадия проверяет ключ перемещения, а стадия успеха или провала — еще и ключ закрытия.
  • search all находит сохраненные сделки и лиды рядом с сообщениями, заметками и событиями других инструментов WireCat. При deals.list: deny он не берет сделки и называет их в missing и в stderr, и так же для лидов; если запрещены все виды, о которых его спросили, он отклоняется (search.all-denied).
  • b24 --help и b24 без аргументов начинаются с того, для чего нужен b24, что попробовать первым и с чего начать.

Изменено — может сломать вызовы

  • deals, leads, pipelines и stages — общие CRM-команды cli-core, одинаковые в каждом CRM-инструменте WireCat. Их списки и show читают локальное хранилище, поэтому сначала запустите sync; --offline теперь работает для них.
  • Сделка или лид называется своим ref, deal:12 или lead:7, как его печатает список, а не id или названием в Битрикс24.
  • Сделка или лид отвечает ref, pipeline и pipeline_name, stage (ее имя), status (open, won или lost), close_date, amount как десятичной строкой в currency, оба null, если суммы нет, assignee как <portal>/user/<id>, а собственными полями портала — в provider_metadata по коду. stage_id, pipeline_id, outcome, closes_on, assigned_to и person_ids из них убраны; контакты лежат в people, компания — в organization.
  • Их запрос списка принимает status, stage, pipeline и organization; свободное слово, временные окна и собственные поля портала из него убраны. --all убран из этих списков.
  • deals move <ref> <stage> принимает стадию как аргумент, а не как --stage.
  • У записи сделок и лидов нет --body. --field <label or code>=<value> задает пользовательское поле по описаниям, которые сохранил последний sync: поле-список принимает подпись или id своего варианта, поле с несколькими значениями — по одному --field на значение, а пустое значение его очищает. Код, который называет стандартное поле (stageId, categoryId, assignedById, STATUS_ID лида), отклоняется, как и --field без ключа перед =.
  • Подпись пользовательского поля и подпись варианта списка сравниваются так, как cli-core сравнивает имена, для каждого --field и запроса: е находит ё, а буква, набранная двумя кодовыми точками, находит ту же букву, набранную одной. people show и organizations show так же сравнивают имя с совпадениями портала. Подпись, которая совпадала с одним полем, теперь может совпасть с двумя, и тогда она отклоняется с обоими.
  • fields list <deals|leads|people|organizations> теперь из cli-core: он читает описания, которые сохранил sync, поэтому сначала запустите sync, и каждое поле называет свои части untrusted.
  • api.crm.deal.update (и другие ключи api.* сделок и лидов) при ask теперь спрашивает и на deals update, move и close, а не только на api call. --dry-run записи сделки или лида называет каждый ключ, который она может проверить: ключ api.*, а также ключи перемещения, закрытия и crm.assign-others с параметром, при котором каждый из них применяется.
  • sync читает описания полей портала для каждого вида, по одному лишнему запросу на вид, поэтому --max-pages доходит до записей позже. Вебхук без прав на их чтение все равно синхронизируется; любая другая ошибка там проваливает синхронизацию.
  • Лиды стоят в одной воронке с именем Leads, потому что у лидов Битрикс24 воронок нет.
  • deals.delete и leads.delete по умолчанию равны ask; api call, который задает стадию, проверяет deals.close (или leads.close) вместе с deals.move.
  • mcp и doctor — общие команды cli-core: mcp добавляет config, add и check, а также --profiles и --permission у serve; doctor добавляет --online.
  • --body или метод api call, которые можно прочитать больше чем одним способом, отклоняются до отправки: тело, которое называет одно поле дважды в любом написании, entityTypeId, который не простое число, fields, который не объект, метод с любым суффиксом, кроме одного .json, и метод crm.item без entityTypeId. Отправляйте каждое поле один раз, в одном написании.
  • --operation-id убран из всех записей. На живом портале создание, повторенное с тем же id, создало вторую запись, поэтому повтор никогда не безопасен: после outcome_unknown выполните sync и show и повторите запись, только если ее там нет. Запись сделки или лида с --operation-id отклоняется до отправки.

Исправлено

  • sync после первого работает. Он спрашивал портал об изменениях со временем, которое портал отклоняет, поэтому каждый вид завершался ошибкой и ничего нового не копировалось. Время в фильтре теперь уходит в целых секундах со смещением, и это же исправляет updated_at: и created_at: в people list и organizations list.
  • Запись, на которую пришел ответ об ошибке сервера или шлюза (500, 502, 504), — это outcome_unknown, а не provider_unavailable: портал мог ее выполнить. Запись, прерванная отменой, — тоже outcome_unknown, никогда не cancelled.
  • Стадии читаются страница за страницей: справочник длиннее первых 50 строк REST 2 терял свои последние стадии.
  • Id или ответственный, который не является числом, отклоняется до отправки; раньше он уходил пустым.
  • --body сохраняет целые числа больше 2^53 как введены; api call --body - читает тело из stdin.
  • Запрос без ответа прерывается через 10 секунд, а не через 30, чтобы чтение можно было повторить до того, как истекут собственные 30 с разовой команды.
  • show для людей и организаций завершается ошибкой, если подписи полей портала не получены по причине, отличной от нехватки прав, а не показывает запись без подписей.

Безопасность

  • Проверки прав в api call и в записи people и organizations читают тело ровно в том виде, в каком оно отправляется, поэтому проверяют тот ключ, который нужен записи.
  • Чтение через api call проверяет те же ключи, что и команды, которые читают эти записи, как уже делала его запись.

0.4.0 — 06.11.2026

Добавлено

  • create и update для сделок, лидов, людей и организаций принимают --field "<label or code>=<value>", повторяя его для других полей или для каждого значения поля с несколькими значениями. Подпись ищется на портале; два поля с такой подписью отклоняются с их кодами. Поле-список принимает подпись или id своего варианта. --field важнее --body для того же поля, а --title, --name, --first-name и --last-name важнее обоих. Остальные значения уходят на портал как введены. --dry-run имена не ищет.
  • list для сделок, лидов, людей и организаций фильтрует по собственным полям портала: <code or label>:<value>, для полей, по которым портал умеет фильтровать; поле-список принимает подпись или id своего варианта. Подпись с пробелами пишется lead_source:web или Lead\ source:web.
  • list --json=…,provider_metadata.<code> добавляет это пользовательское поле к каждому элементу так, как его выдает show; --json=…,provider_metadata добавляет все. Запрашиваются только коды, которые перечисляет портал.
  • fields list <deals|leads|people|organizations> перечисляет пользовательские поля портала этого вида: код, подпись, тип, держит ли поле несколько значений, может ли список по нему фильтровать, а для поля-списка — его варианты с их id.

Изменено — может сломать вызовы

  • show выдает значение поля-списка подписью его варианта, а не id; id переезжает в option_id рядом. Поле с несколькими вариантами выдает и то, и другое массивами.
  • api call работает по списку разрешенного. Чтение CRM, каталога и пользователей и запись четырех типов CRM разрешены, как и раньше. Любой другой метод спрашивает, поэтому без терминала ему нужен --yes, а семейства, которые пишут людям, публикуют или отправляют данные наружу, запрещены: imconnector, log.blogpost, публичные ссылки на файлы и event.bind присоединяются к im, imopenlines и остальным. api show называет уровень каждого метода.

Исправлено

  • deny в профиле снова останавливает команду чтения. b24 передавал cli-core только resolveSettings, поэтому cli-core никогда не видел таблицу прав b24: deals.list: deny не останавливал deals list, в том числе через MCP, а с любым ключом b24 в настройках каждый --dry-run падал с «names no command».
  • api.crm.<type>.add и api.crm.<type>.update теперь действуют на create, update и move у deals, leads, people и organizations, как ключи команд уже действовали на api call. --dry-run называет их рядом с собственным ключом команды.
  • api call --dry-run называет каждый ключ, который проверяет вызов, с его уровнем, например api.crm.deal.delete при ask, вместо «no key, allowed».
  • api call crm.item.add|update|delete с entityTypeId от 1 до 4 проверяет ключ команды лида, сделки, контакта или компании, как уже делал crm.deal.update: deals.delete: deny теперь останавливает crm.item.delete для сделки.
  • Каждый метод, имя которого заканчивается на delete, спрашивает, а не только перечисленные. Имя метода заглавными буквами или с суффиксом .json читается как его простое имя, поэтому больше не обходит ключ.
  • Запись, которая задает стадию, проверяет deals.move или leads.move: update и create со stageId в --body, в том числе через MCP, и api call со STAGE_ID или STATUS_ID лида. ASSIGNED_BY_ID проверяет crm.assign-others, как и assignedById.
  • Запись отправляется один раз. Запись REST 3.0, на которую не пришел ответ, отправлялась до трех раз еще с тем же Idempotency-Key, что на живом портале еще не проверено; теперь она сразу становится outcome_unknown, и ее сообщение один раз называет --operation-id.
  • pipeline_id:0, воронка по умолчанию, принимается в deals list и stages list.
  • Список разрешенного, как и до него, оставляет отклоненным чтение запрещенных семейств: crm.activity.list, im.*, tasks.* и остальные — deny, и api show так и говорит.
  • Сервер MCP применяет таблицу прав b24 (WC-PERM-23): команда, которую профиль запрещает, показывается в поиске инструментов как недоступная, а не предлагается как доступная.

0.3.0 — 06.11.2026

Изменено — может сломать вызовы

  • show для сделок, лидов, людей и организаций выдает каждому пользовательскому полю его название на портале: provider_metadata сопоставляет коду поля { "label", "value" }. label равен null, если у портала нет названия для поля или он не отвечает на запрос названий; show при этом все равно отвечает.

0.2.0 — 06.11.2026

Исправлено

  • Команды, которые обращаются к порталу, теперь выполняются внутри запуска cli-core: meta.run_id каждого ответа называет запуск, который находит runs show, с запросами к порталу в нем, meta.duration_ms измеряет команду, а --timeout останавливает зависшую команду. Переопределения прав агента MCP теперь тоже доходят до этих команд.
  • show для сделок, лидов, людей и организаций больше не перечисляет пользовательские поля портала без значения: provider_metadata пропускает null, "" и [] и сам пропускается, если ничего не осталось.

0.1.0 — 06.11.2026

Исправлено

  • Причина ошибки, которую определяет и более новый cli-core, больше не роняет каждую неудачную команду вместо того, чтобы напечатать ее ошибку.

Добавлено

  • Создан из @wirecat/cli-template 0.14.0.
  • Клиент REST API Битрикс24 через входящий вебхук: REST 3.0 для сделок, лидов, контактов и компаний, REST 2 для остального; ограничения частоты портала соблюдаются и выжидаются; запись повторяется только с Idempotency-Key; секрет вебхука не попадает ни в одну ошибку и запись запуска.
  • session start | status | end для каждого профиля и session list: адрес вебхука читается скрыто или из stdin, проверяется на портале и хранится в связке ключей под bitrix24-cli; session status --check показывает, чьи права у вебхука.
  • list и show для deals, leads, people (контакты), organizations (компании), pipelines, stages (с исходом каждой стадии), products и users, напрямую с портала. Список принимает запрос, который становится собственным фильтром портала; свободное слово в нем совпадает с частью названия или имени. Имя, общее для двух записей, отклоняется, и обе показываются как кандидаты.
  • create и update для deals, leads, people и organizations, а также move для сделок и лидов: каждая запись отвечает своим operation_id, который Битрикс24 получает как Idempotency-Key, поэтому --operation-id безопасно повторяет запись; --dry-run показывает ее заранее; назначение записи другому сотруднику запрещено, пока его не разрешат (crm.assign-others).
  • api list, api show <method> и api call <method> --body <json>: любой метод Битрикс24, на той версии REST, где он находится, с проверкой api.<method> и ключа команды, которая делает то же самое; запись сообщений, автоматизации, задач и batch запрещена, пока ее не разрешат.

Безопасность

Предыдущая страница

Планы развития

Следующая страница