---
title: "Claude Code – команди, настройки, флагове"
url: "https://romankryvolapov.com/bg/claude-code-commands-and-settings/"
description: "Справочник за Claude Code: слеш команди с аргументи и примери, ключове на settings.json, правила за достъп, подкоманди, флагове и променливи на средата. Актуално към август 2026."
language: bg
published: 2026-08-31
updated: 2026-11-13
---
**Здравейте!**

Това е справочник. Не разказ как се работи правилно с агента – за това имам [отделна статия](/bg/claude-code-best-practices/) – а списък: какво може да се въведе, какво може да се запише в настройките, кое какво прави и как изглежда на практика.

**Актуалност: август 2026.** Списъците с команди, ключове и флагове са снети от билд **2.1.251**, а онова, което можеше да се провери със стартиране, е проверено на **2.1.252**. За техническа статия версията е по-важна от обикновено: между съседни билдове командите изчезват, сменят имената си и си разменят местата. Ако вие имате друга версия, `/help` и `claude --help` винаги са прави, а аз – само към момента на писане.

Изходът от конзолата в примерите е истински: или е снет от работещ билд, или е взет от официалната документация. Където не успях да намеря реален изход, няма никакъв, а какво ще се случи след командата, е описано с думи – измислени екрани в статията няма да има.

## Три места, където се въвеждат команди

Преди да прелистите таблиците, полезно е да разберете, че повърхностите са три и не се застъпват.

**Слеш командите** се въвеждат вътре в работеща сесия, със `/` в началото на реда. Те управляват разговора: смяна на модела, свиване на контекста, връщане на промени, стартиране на ревю. В терминала не работят.

**`settings.json`** е файл на диска. Той определя с какво състояние ще стартира Claude Code: кой модел, какви права имат инструментите, какви хукове, какво да се показва в статус реда. Значителна част от настройките съществуват само тук и нямат команда-еквивалент.

**Терминалните команди `claude`** се въвеждат в обикновената командна обвивка, преди сесията или извън нея: инсталиране, автентикация, MCP сървъри, плъгини, фонови агенти, неинтерактивно стартиране за скриптове.

Разделението не е декоративно. Половината от въпросите от рода на „защо не работи“ се обясняват с това, че човек е написал `/model` в терминала или `--effort` във файла с настройки. Има обаче и приятно изключение: в неинтерактивния режим `claude -p` слеш командите в текста на промпта работят – за това по-нататък има отделен раздел.

## Слеш команди

Въвеждат се вътре в работеща сесия, със `/` в началото на реда. За всяка команда по-долу всичко е събрано накуп: аргументи с всички стойности, тънкости и примери.

Обозначения: **[Скил]** – вграден скил, тоест готов сценарий-промпт; **[Воркфлоу]** – вграден мултиагентен воркфлоу; **[извън плана]** – плаща се с кредити отделно от абонамента; **[не във всички планове]** – наличността зависи от плана, организацията или доставчика; **[няма в документацията]** – има го в билда, а в публичните източници не е описано.

За примерите. В блоковете е онова, което реално се въвежда, с истински аргументи, а не голото име на команда. Изходът е показан там, където е могло да се вземе от работещ билд или от официалната документация; той е на английски, защото така се отпечатва. Където достоверен изход няма, няма го и тук, а какво ще се появи на екрана и между какво ще трябва да се избира, е казано с думи в описанието на командата. Измислени екрани в статията няма да има.

Командите, които в този билд са изключени или напълно премахнати, нямат свои раздели – събрани са в таблица в края на този раздел.

### Сесии и разговор

Четирите команди от тази група правят сходни неща и постоянно се бъркат. Разликата е в това какво се копира и къде се появява резултатът:

| Команда | Какво се копира | Къде върви работата | Къде отива резултатът |
|---|---|---|---|
| `/branch` | целият разговор | тук, продължавате в разклонението | в разклонението; оригиналът остава недокоснат |
| `/fork` | целият разговор | във фонова сесия, паралелно с вас | в отделна сесия, към която се свързвате по-късно |
| `/subtask` | целият контекст, еднократно | в субагент | обратно в същия разговор с едно съобщение |
| `/background` | нищо не се копира | същата сесия си отива на фон | в нея самата, когато се върнете при нея |

#### `/clear [име]`

Започва нов разговор с чист контекст. Псевдоними: `/reset`, `/new`. Прибягвате към нея при преминаване към друга задача: старият контекст престава да помага и започва да пречи – моделът продължава да тегли в отговорите подробности от предишната работа.

Старият разговор не се изтрива – остава на диска и се отваря чрез `/resume`. Незадължителният аргумент му дава име в списъка: без име след седмица ще гледате десетина безименни реда.

Ако сте изчистили случайно, в същия процес това се отменя: в менюто на `/rewind` има запис за предишната сесия, който изглежда като `/resume <id> (previous session)`.

Струва си да помните и цената: `/clear` не струва нищо, докато `/compact` е голяма заявка с целия контекст. Ако разговорът вече не ви трябва, изчистването е по-евтино от свиването с целия обем на прозореца.

```
/clear                                    # нов разговор с чист контекст
/clear експеримент с опашки, не се получи  # същото, но предишният разговор е подписан с тази фраза
```

#### `/resume [id или фраза за търсене]`

Връща ви към минал разговор. Псевдоним: `/continue`. Нужна е, когато работата е била прекъсната и искате да продължите не от нулата, а с целия натрупан контекст – или когато трябва да извадите отдавнашно обсъждане, за да си спомните докъде сте стигнали тогава.

| Какво подадете | Какво ще се случи |
|---|---|
| нищо | Ще се отвори интерактивен списък с последните сесии на тази папка |
| идентификатор на сесия | Тя ще се отвори веднага, без списък |
| произволен текст | Търсене в съдържанието на разговорите; от съвпадналите се предлага да изберете |

Списъкът е вързан към **работната папка**: разговор от друг проект в него няма да се появи. А по идентификатор сесията се отваря от всяка папка на машината – до версия 2.1.223 се е търсело само в текущия проект и в неговите работни копия. За скриптове това е удобно: взели сте `session_id` от изхода на `claude -p --output-format json` и сте продължили от където и да е.

Транскриптите се чистят по `cleanupPeriodDays`, по подразбиране след тридесет дни. Ако смятате да се връщате към стари разговори, вдигнете стойността предварително – няма откъде да се възстанови изтритото.

Терминални форми: `claude -c` продължава последния разговор на папката без избор (фоновите сесии пропуска), `claude -r` отваря същия избор преди старта на сесията, `claude -r <id> --fork-session` продължава стар разговор с нов идентификатор, като оставя изходния недокоснат.

В списъка избирате кой от минали разговори да продължите: всеки ред е отделна сесия на тази папка със свой надпис и време. Избраният се отваря изцяло, с цялата кореспонденция и контекст, и пишете в него нататък, сякаш нищо не се е случвало.

```
/resume                    # избор от последните разговори на тази папка
/resume 8f3c1d2e-4b5a-...  # отваряне веднага по идентификатор, без избор
/resume дедлок в пула      # търсене по съдържание; избор от съвпадналите разговори
```

#### `/branch [име]`

Разклонява разговора от текущата точка; оригиналът се запазва изцяло.

Това е като запис на играта преди срещата с боса. Намирате се в точка, в която не е ясно кой от двата подхода е по-добър; разклонявате се, пробвате първия и ако не се получи – връщате се в оригинала чрез `/resume` и пробвате втория, без да влачите в контекста неуспешния опит. Името е незадължително, но с него по-късно е по-лесно да намерите нужния клон в списъка.

След командата се оказвате в разклонението и пишете нататък вече в него; изходният разговор остава цял и се отваря чрез `/resume`.

```
/branch                            # разклоняване от текущата точка
/branch опитай-през-опашка         # същото, разклонението е подписано с това име
```

#### `/fork [задача]`

Копира разговора във фонова сесия, която работи по задачата паралелно с вас.

Това е „нека някой се заеме с това, докато аз правя своето“. Копието получава целия натрупан контекст; резултата ще вземете, като се свържете с него чрез `claude attach` или екрана `claude agents`. Започвайки от 2.1.221, на копието освен това е наредено да си създаде собствено работно копие на git, преди да променя код – за да не си пречат двата агента в едно и също дърво.

**Внимавайте с чужди инструкции.** Във версиите от 2.1.161 до 2.1.211 онова, което сега се нарича `/subtask`, се наричаше `/fork`, а имената се разменят в 2.1.212. Статия или скрипт, писани преди това, имат предвид точно обратното. Плюс частен случай: ако екранът на агентите е изключен, `/fork` се връща към старото поведение и работи като субагент.

Имайте предвид и разхода: копието е пълноценна втора сесия със свой контекст и докато работи, лимитът се харчи едновременно с вашия.

Копието се създава веднага и получава свой идентификатор – той е нужен, за да се свържете с него по-късно. Със задание то се залавя за работа незабавно, без задание просто чака указания.

```
/fork събери бележките към изданието по комитите от предишния таг  # копието работи паралелно с вас
/fork                                                              # копието чака указания
```

#### `/subtask <задача>`

Изпраща субагент с вашия контекст; резултатът се връща в същия разговор.

Това е „иди да видиш и се върни“. Разликата от `/fork` е принципна: шумната част от работата – четене на двадесет файла, дълги листове с изход – остава в контекста на субагента, а при вас идва само изходът. Основният начин да не запушвате основния контекст с разузнаване.

Изисква версия 2.1.212; преди нея тази команда се наричаше `/fork`. При изключен екран на агентите е недостъпна.

При това се спестява вашият контекстен прозорец, а не разходът: субагентът чете и мисли за сметка на същия ваш лимит, просто не оставя боклук в разговора.

Разговорът не спира: докато субагентът чете, вие продължавате да пишете, а когато завърши, в кореспонденцията се появява едно негово съобщение с резултата.

```
/subtask намери всички извиквания на този метод                                          # разузнаване без боклук в контекста
/subtask прочети миграциите за месеца и кажи какво се е променяло в схемата на поръчките  # същото за дълго четене
```

#### `/background [промпт]`

Изпраща текущата сесия на фон и освобождава терминала. Псевдоним: `/bg`.

Нищо не се копира – на фон отива самата тази сесия, работата продължава. С аргумент ѝ давате и задание за из път. Връщате се после чрез `claude attach` или екрана `claude agents`; спира се с `/stop` или `claude stop <id>`. Прибягва се към нея, когато задачата е дълга, а терминалът ви трябва веднага.

Терминалът се освобождава веднага, а сесията остава да живее на фон под свой идентификатор – по него се връщате при нея.

```
/background                           # отиване на фон и освобождаване на терминала
/bg догони билда и оправи линтера     # същото, плюс задание за из път
```

#### `/rename [име]`

Преименува сесията. Псевдоним: `/name` **[няма в документацията]**. Смисълът е чисто практичен: когато отворените и фоновите разговори станат много, те трябва да се различават по име, а не по идентификатор.

Името се вижда в реда за въвеждане, в списъка на `/resume` и в заглавието на раздела на терминала. Без аргумент се генерира по темата на разговора.

С въведеното име стават три неща: управляващите и невидимите символи се заменят с интервали, дължината се отрязва до двеста знака, а ако след почистването не е останало нищо, името се отхвърля като празно. Ако такова име вече е заето от друга жива сесия на тази машина, ще се приложи негов вариант – не е грешка, просто името ще е малко по-различно.

Заглавието на терминала се сменя, ако е включено `terminalTitleFromRename` (по подразбиране – да); да се забрани изобщо пипането на заглавието може с променливата `CLAUDE_CODE_DISABLE_TERMINAL_TITLE`.

```
/rename                         # името се измисля по темата на разговора
/rename рефакторинг на плащането  # името е зададено ръчно
```

#### `/cd <път>`

Премества сесията в друга работна папка. Полезна е, когато работата се е преместила в съседна услуга или хранилище, а не искате да зарязвате разговора.

Настройките, хуковете, MCP сървърите, скиловете и агентите на новата папка започват да действат веднага, а не след рестарт, и блокът `env` на новата папка се наслагва върху стария. С това `/cd` се различава от `/add-dir`, която дава достъп до файловете, но не и до конфигурацията.

```
/cd ../backend  # преместване в съседното хранилище заедно с неговата конфигурация
```

#### `/recap`

Свива цялата сесия до един ред-резюме – бързо да си спомните за какво е ставало дума. Полезна е след почивка и в дълъг разговор, където началото вече е излязло извън екрана. Контекстът при това не се пипа: това е просто кратка извадка като отговор, а не свиване на разговора, с което се занимава `/compact`.

```
/recap  # за какво е този разговор и до какво се е стигнало в него
```

#### `/btw [въпрос]`

Задава кратък страничен въпрос, без да замърсява основния контекст: отговорът не се примесва в по-нататъшната работа. Това е за „а как се казва това нещо“ насред задача – за да не гради моделът след десет съобщения разсъждения около случайно зададен въпрос.

Без въпрос отваря предишните ви странични въпроси, за да прелистите отговорите; до версия 2.1.212 въпросът е бил задължителен.

```
/btw с какво се различава grpc-web от grpc  # отговорът е видим за вас, но минава встрани от по-нататъшния контекст
/btw                                         # връщане към предишните странични въпроси
```

#### `/export [файл]`

Изнася разговора във файл или в клипборда. Обикновено е нужно, за да приложите кореспонденцията към задача, да я препратите на колега или да запазите разбор, към който ще се върнете.

Без аргумент целият разговор отива в клипборда, с аргумент се записва във файл; `~` се разгъва. Форматът е текстов, с разметка на ролите: това е транскрипт за човек или за подаване на друг инструмент, а не машинен формат за импортиране обратно.

```
/export                    # целият разговор в клипборда
/export ~/logs/session.md  # същото, но във файл
```

#### `/copy [N]`

Копира в клипборда един отговор: без аргумент последния, с число – N-тия от края. Нужна е, когато от голям отговор трябва да вземете част в редактора или в тикета и не ви се иска да маркирате с мишката половин екран.

Броят се отговорите на асистента, а не редовете на екрана, затова `/copy 2` означава „предпоследният отговор“. Малко известно: **ако в отговора има блокове код, се отваря избор** – може да вземете отделен блок, а не цялото съобщение. И точно там клавишът `w` записва избраното във файл вместо в клипборда; по SSH, където клипбордът е безполезен, това е единственият работещ начин.

Изборът в този списък е между цялото съобщение и всеки отделен блок код от него; избраното веднага отива в клипборда, а при `w` – във файл.

```
/copy    # последният отговор в клипборда
/copy 2  # предпоследният; ако в него има код, първо ще ви предложат да изберете блок
```

#### `/stop`

Спира текущата фонова сесия. Транскриптът и работното копие се запазват. Нужна е, когато фоновата работа е тръгнала накриво или вече не е нужна: сесията наистина преустановява работа, а не просто се отделя, както при `/exit`. Отвън същото прави `claude stop <id>`.

```
/stop  # спиране на фоновата сесия, транскриптът и работното копие остават
```

#### `/exit`

Излиза от CLI. Псевдоним: `/quit`. Във фонова сесия – отделя се, самата сесия продължава да работи.

```
/exit  # изход от CLI; във фонова сесия – само отделяне
```

### Контекст и памет

#### `/context [all]`

Показва с цветна мрежа с какво е запълнен контекстът, плюс съвети какво може да се разтовари. Аргументът `all` разгъва подробностите: кои точно файлове и колко заемат. Прибягвате към нея, когато сесията е натежала осезаемо или е на път да премине в автосвиване: командата показва кой точно е заел прозореца, а от това зависи с какво се лекува. Не я бъркайте с `/usage`: тя е за лимитите на плана, а тази – за прозореца на текущата сесия.

Всяка клетка на мрежата е парче от контекстния прозорец, оцветено по източник. Смисълът не е в красотата: източниците се държат различно и се лекуват различно.

| Какво показва | Откъде се взема | С какво се намалява |
|---|---|---|
| Системен промпт | самият Claude Code | почти с нищо; `--bare` и `--restricted` го орязват |
| Описания на инструментите | вградените плюс MCP сървърите | да се изключат ненужните сървъри |
| Листинг на скиловете | описанията на всички налични скилове | `skillOverrides`, `skillListingBudgetFraction` |
| Файлове с памет | `CLAUDE.md` и автопаметта | да се съкратят или изключат чрез `claudeMdExcludes` |
| История на разговора | вашите съобщения и отговорите | `/compact`, `/clear` |
| Прочетени файлове и изход от команди | инструментите | `/clear`, а разузнаването да се даде на `/subtask` |

Практическата стойност е именно в `all`: почти винаги се намират един-два файла или един приказлив MCP сървър, изяли повече от цялата полезна работа.

Нататък има развилка. Историята се е раздула – `/compact`. Раздули са се прочетените файлове – `/clear` и започвате отначало. Раздули са се описанията на инструменти и скилове – това се лекува с настройки, а не с команди: в следващата сесия контекстът ще е точно толкова раздут.

```
/context                                # с какво е зает контекстът в момента

Context Usage
Opus 5 (1M context)
claude-opus-5[1m]
138.8k/1m tokens (14%)

Estimated usage by category
  System prompt:    4.4k tokens  (0.4%)
  System tools:      21k tokens  (2.1%)
  MCP tools:         265 tokens  (0.0%)
  Memory files:     3.2k tokens  (0.3%)
  Skills:           6.2k tokens  (0.6%)
  Messages:       104.2k tokens (10.4%)
  Free space:      860.7k       (86.1%)

MCP tools · /mcp (loaded on-demand)
└ 126 tools · 265 tokens

Memory files · /memory
└ 1 file · 3.2k tokens

Skills · /skills
└ 48 skills · 6.2k tokens

/context all to expand

 Suggestions
 ℹ File reads using 76.1k tokens (8%) → save ~22.8k
   If you are re-reading files, consider referencing earlier reads.
   Use offset/limit for large files.

/context all                            # същото, с разбивка по всеки файл
```

Изходът по-горе е дословно копие на реална сесия на Opus 5 с прозорец от милион токена.

#### `/compact [инструкции]`

Свива историята на разговора до резюме, освобождавайки място. Аргументът не е флаг и не е филтър, а инструкция към съставителя на резюмето: на какво да обърне внимание, какво не бива да се загуби. Нужна е, когато прозорецът е почти пълен, а е рано да зарязвате разговора: работата ще продължи от същото място, но нататък ще се опира на преразказ.

Свиването е загуба. Резюмето го пише моделът, то неизбежно е по-кратко от оригинала и всичко, което не е попаднало в акцента, се възпроизвежда приблизително или изчезва. Смисленият аргумент не е учтивост, а начин да управлявате какво точно сте съгласни да загубите.

Без да пита нищо, командата свива историята и отчита с един ред; самото резюме по подразбиране е свито и се разгъва с отделно натискане. С аргумент външно нищо не се променя – разликата е само в това, какво е задържано вътре в резюмето.

Самото свиване е скъпа заявка: в нея отива целият контекст. `/clear` не струва нищо. Ако разговорът вече не ви трябва, втората команда е по-евтина от първата с целия обем на прозореца.

Прагът, при който контекстът се свива сам, се управлява с `/autocompact`.

```
/compact                                # свиване на историята както се получи

⎿ Compacted (ctrl+o to see full summary)

/compact запази решенията по схемата на базата данни     # свиване, но без да се загуби тази линия

/compact остави само онова, което се отнася до модула за плащане
```

Редът на отчета е приведен дословно, снет е на билд 2.1.220.

#### `/autocompact [auto|<токени>]`

Настройва при какво запълване контекстът започва да се свива сам. Командата се появи в 2.1.221. Прагът е компромис: колкото е по-висок, толкова по-дълго живее пълната история, но толкова по-близо сте до тавана на прозореца; колкото е по-нисък, толкова по-често разговорът се превръща в преразказ. Към командата се прибягва, когато свиването се задейства не навреме – твърде рано и отнася нужното, или твърде късно и опира в тавана.

| Аргумент | Какво прави |
|---|---|
| без аргумент | Показва текущата стойност |
| `auto` | Прагът се подбира автоматично |
| число от 100000 до 1000000 | Свива при достигане на този брой токени |

Стойности извън диапазона не се приемат. Постоянният еквивалент е ключът `autoCompactWindow`, автосвиването се изключва изцяло с `autoCompactEnabled: false`, има и флаг за стартиране `--autocompact` със същите стойности. Отделната настройка `precomputeCompactionEnabled` подготвя свиването предварително, докато върви обичайната работа – когато прагът бъде достигнат, паузата ще е по-кратка; работи само при включено автосвиване.

Диалог командата не отваря: без аргумент просто показва действащия праг, с аргумент – приема нов или отказва, ако числото е извън допустимия диапазон.

```
/autocompact                            # преглед на текущия праг

/autocompact auto                       # нека се подбира сам

/autocompact 400000                     # свиване при достигане на 400k токена
```

#### `/memory`

Отваря файловете с памет за редактиране и позволява да ги управлявате. Паметта се примесва в контекста на всяка сесия, затова това е едновременно основният лост за влияние върху поведението на агента и постоянен данък върху прозореца: за всичко, което е там, плащате във всяка заявка. Първо избирате кой файл да редактирате – проектният или вашият личен – и той се отваря в редактора.

Кои от тях се зареждат, показва `/context`, а да ги приведе в ред умее `/doctor`: той чисти дубликатите, пренася рядко нужното в отделни файлове, зареждани при поискване, и изрязва онова, което агентът така или иначе ще изведе от кода.

```
/memory                                 # отваряне на файловете с памет за редакция
```

#### `/init`

Създава `CLAUDE.md`: агентът ще огледа хранилището и ще опише структурата и командите му. **[Скил]** Прибягвате към нея в хранилище, с което агентът още не е работил; вече съществуващ файл обикновено е по-бързо да се поправи на ръка през `/memory`, отколкото да се генерира наново.

`CLAUDE.md` е файл с инструкции, който се примесва в контекста на всяка сесия.

След като е сработила успешно, командата не отпечатва нищо. Документацията съветва резултатът да се провери в следващата сесия: извикайте `/context` и се уверете, че `CLAUDE.md` се е появил в раздела **Memory files**.

Малко известна променлива: `CLAUDE_CODE_NEW_INIT=1` включва интерактивния вариант, който води не само през инструкциите на проекта, но и през скиловете, хуковете и личните файлове с памет. А ако в папката се намери конфигурация на друг кодинг агент, която `/import` умее да пренася, ще ви предложат да я вземете.

```
/init                                   # генериране на CLAUDE.md по хранилището
```

```bash
CLAUDE_CODE_NEW_INIT=1 claude    # интерактивен /init със скилове и хукове
```

#### `/add-dir <път>`

Добавя още една работна директория, за да вижда агентът файлове извън папката на проекта. Нужна е, когато работата не се побира в едно хранилище: съседна услуга, обща схема, изнесена библиотека – без това агентът просто няма да ги прочете.

Важна тънкост: тя дава достъп **до файловете**, а не до конфигурацията – хуковете и настройките на тази папка не се вземат. Единственото изключение са скиловете и командите: те се вземат от добавената папка. Да преместите сесията изцяло в друга папка, заедно с настройките и хуковете ѝ, е `/cd`, а не `/add-dir`.

```
/add-dir ../shared-protocol             # пускане на агента в съседното хранилище
```

#### `/rewind`

Връща кода и/или разговора към контролна точка или свива част от разговора. Псевдоними: `/checkpoint`, `/undo`. Нужна е, когато серия промени е завела накриво и да разберете какво точно е натворил агентът отнема повече, отколкото да се върнете една стъпка назад.

Първото, което трябва да знаете: **командата не работи винаги.** Копията на файловете се снемат преди промяна само ако е включено `fileCheckpointingEnabled`. Изключено е – няма какво да се възстановява.

Второто: менюто се отваря не само с команда. **Двойно `Esc` в празен ред за въвеждане** прави същото. Ако в реда има текст, двойното `Esc` го изчиства – затова първо изчистете реда.

В менюто има шест пункта и половината от тях не са за връщане:

| Пункт | Какво прави |
|---|---|
| Възстановяване на код и разговор | Пълно връщане към състоянието в момента на точката |
| Възстановяване на разговор | Историята се връща, файловете остават както са |
| Възстановяване на код | Файловете се връщат, разговорът остава цял |
| Свиване оттук | Свива разговора от избраната точка нататък |
| Свиване до това място | Свива всичко, което е било до избраната точка |
| Отказ | Нищо не се прави |

Двата пункта за свиване са, по същество, прицелен `/compact`: освобождаване на контекст, но не на целия разговор, а на конкретна негова част. В реда има незадължително поле за указания на какво да се обърне внимание при свиването, а на мястото на свитото остава бележка.

Изборът тук е двустъпков: първо точката, към която се връщате, после едно от шестте действия над нея. От връщанията най-често е нужно „възстановяване на код“: промените са тръгнали накриво, но обсъждането, от което са поникнали, е ценно и да се загуби е глупаво.

**Граници, които е добре да знаете, преди да са ви потрябвали.** Пазят се сто последни контролни точки, а заедно със сесията се изтриват след тридесет дни – същият `cleanupPeriodDays`. Не се възстановява: онова, което са направили стартираните команди на командната обвивка, повечето промени на субагенти, промените, внесени отвън, и всичко, до което се стига през символни и твърди връзки. Тоест базата данни, изтрита от миграция, няма да се върне, `git reset` няма да се отмени, инсталираните пакети ще останат. Това е отмяна на последните промени, а не система за контрол на версиите и не замяна на комитите.

Възстановяването на код не винаги е пълно: ако на файла от момента на точката му се е сменил типът или директорията, той ще бъде пропуснат, а сесията отделно ще съобщи колко файла не е докоснала.

```
/rewind                                 # меню за връщане и свиване
```

### Модел и производителност

#### `/model [модел]`

Сменя модела и запомня избора. **[извън плана]** плаща не самата команда, а част от онова, което с нея може да се избере: Fable 5 и вариантите с контекстен прозорец от милион токена в редица планове се таксуват с кредити извън абонамента и без включени кредити тези редове в списъка не работят. Без аргумент се отваря списък с наличното. Към командата се прибягва, когато се е сменил характерът на работата: тежък разбор има смисъл да се води на най-силния модел, а поток от дребни промени – на бърз и евтин.

| Какво подадете | Какво ще се случи |
|---|---|
| нищо | Ще се отвори списък с наличните модели |
| псевдоним на семейство – `opus`, `sonnet`, `haiku`, `fable` | Ще се вземе текущият модел на това семейство |
| `default` | Моделът по подразбиране за вашия план |
| `best` | Fable 5 там, където организацията има достъп, иначе най-новият Opus |
| `opusplan` | Планиране с Opus, изпълнение със Sonnet |
| `opus[1m]`, `sonnet[1m]` | Същият модел с контекстен прозорец от милион токена |
| префикс на версия, например `opus-5` | Ще се разреши в конкретен модел |
| пълен идентификатор | Ще се вземе точно той |

Изборът се запомня и преживява рестарт – с това `/model` се различава от променливата `ANTHROPIC_DEFAULT_MODEL`, която той замества.

**Положение към август 2026.** Актуалните модели са Opus 5, Sonnet 5, Fable 5 и Haiku 4.5. Haiku 5 не съществува: псевдонимът `haiku` продължава да сочи към 4.5 и това редовно заблуждава хората при четене на примери с `fallbackModel`.

Какво стои зад псевдонима, **зависи от доставчика**, и това е неочевидна подробност за онези, които работят през облака. На собственото API `sonnet` е Sonnet 5, в Amazon Bedrock и Google Cloud – Sonnet 4.5, в Microsoft Foundry `opus` е изобщо Opus 4.6. Една и съща конфигурация при два доставчика дава различни модели.

Всичко това се настройва по три начина. Какво стои зад псевдонимите – с променливите `ANTHROPIC_DEFAULT_OPUS_MODEL` и сродните им (за `best` такава променлива няма). Самият списък за избор – с ключа `modelPicker`: в него се дописват свои редове с надписи, включително идентификатори на Bedrock и Vertex, а `replaceBuiltInOptions` заменя вградения списък изцяло. Отгоре всичко се ограничава от корпоративния `availableModels`; от версия 2.1.205 псевдонимът на семейство при това не се отхвърля, а се разрешава в най-новия разрешен модел.

Отделно живее `fallbackModel` – списък с модели, към които Claude Code ще превключи сам, ако основният е претоварен. Това не е смяна на вашия избор, а застраховка за времето на недостъпност.

**Какво точно се таксува отделно.** При Fable 5 разчетът с кредити зависи от плана и от типа място в организацията; там, където действа, в списъка на този ред има бележка, че са нужни кредити, а преди първата такава заявка Claude Code веднъж ще поиска потвърждение. В неинтерактивния режим (`-p`) и през Agent SDK този въпрос го няма – таксуването ще стане тихо. С прозореца от милион токена картината е друга: при Sonnet 4.6 той изисква кредити във всеки абонаментен план, включително Max; при Opus – само в Pro, а в Max, Team и Enterprise влиза в плана без никаква настройка. При Sonnet 5 на собственото API прозорецът от милион токена е винаги включен и не изисква кредити.

В списъка избирате между семействата и конкретните версии: вижда се кое е налично във вашия план и при кои редове има изискване за кредити. С аргумент списъкът не се отваря – моделът се сменя веднага. Избраният модел се прилага към текущата сесия и остава избран и следващия път.

```
/model                # избор от наличния списък
/model opus           # по псевдоним
/model opusplan       # планиране с Opus, изпълнение със Sonnet
```

#### `/effort [ниво|auto|status]`

Нивото на усилия задава колко моделът мисли над хода. Това не е същото като избора на модел: моделът определя кой мисли, усилията – колко. Практическият смисъл е да търгувате време и разход на токени срещу качеството на хода: при очевидна промяна дълбоките разсъждения само забавят работата, а при заплетен дефект икономията върху тях води до погрешна диагноза.

| Стойност | Какво се случва | Кога има смисъл |
|---|---|---|
| `low` | Минимум разсъждения, отговор почти веднага | Механични промени, преименувания, въпроси с очевиден отговор |
| `medium` | Обичайният режим | Ежедневна работа |
| `high` | Забележимо повече разсъждения преди действие | Задачи, при които грешката струва по-скъпо от чакането |
| `xhigh` | Максимум разсъждения в обичайния режим | Проектиране, разбор на заплетен дефект |
| `max` | Същото, с упор върху пълнотата | Рядко; преди необратими промени |
| `ultracode` | `xhigh` плюс постоянна оркестрация на воркфлоу | Големи декомпозируеми работи, където цената не е приоритет |
| `auto` | Нивото се подбира според задачата | Стойност по подразбиране, ако не сте се намесвали |
| `status` | Нищо не променя, показва текущото ниво | – |

Четири неочевидности.

**`max` не може да се запази в настройките.** Ключът `effortLevel` приема само стойности до `xhigh`. Максимумът се задава за сесията – с команда или с флага `--effort max` – и нарочно не остава включен завинаги. Така е устроен и `ultracode`: командата и флагът работят, а сред изброените в схемата стойности него го няма; постоянно се включва с отделен булев ключ `ultracode`.

**Нивото се помни по модел.** От версия 2.1.248 всеки модел има свое запазено ниво: превключили сте на друг – получавате неговата настройка, а не последната ви.

**Други команди го отменят.** `/code-review high` повишава усилията за хода, `/code-review low` ги понижава, дори сесията да е вървяла на `xhigh`.

**Думата `ultracode` работи направо в текста на промпта** – по подразбиране е достатъчна, за да включи оркестрацията за един ход; за това отговаря `workflowKeywordTriggerEnabled`. Ако е сработила случайно, отменя се на място с Alt+W (на macOS Option+W). За да стартирате веднага с нея: `claude --effort ultracode`.

Отделно за разхода при `ultracode`. Извън плана не се таксува, но една ваша заявка се разгръща в няколко воркфлоу подред, а всеки воркфлоу ражда агенти – лимитът на плана при това се топи забележимо по-бързо, отколкото при обикновена сесия. Предупреждението за голямо изпълнение, което Claude Code показва, когато са планирани повече от 25 агента или прогнозата надхвърля милион и половина токена, в режим `ultracode` не се извежда: включвайки го, вече сте се съгласили на големи изпълнения. В плана Pro оркестрацията на воркфлоу първо трябва да се включи в `/config`.

Още в 2.1.251 поправиха един частен случай, на който лесно се попада: Opus 5 отказваше да работи с `xhigh` и `max`, ако разсъжденията са изключени. Сега при такава комбинация усилията просто се изпращат като `high`.

С аргумент нивото се превключва на място, за текущата сесия; `status` нищо не променя и само показва действащото ниво.

```
/effort status     # какво е нивото сега
/effort low        # евтино и бързо
/effort ultracode  # xhigh плюс постоянна оркестрация на воркфлоу
```

#### `/fast [on|off]`

Fast режим: същият модел, но с ускорено генериране на отговорите. **[извън плана]** безплатна норма няма – режимът винаги се плаща с кредити извън абонамента, дори лимитът на плана още да не е изчерпан, а докато кредитите не са включени, командата ще съобщи, че са нужни, и нищо няма да превключи. Към него се прибягва там, където чакането е по-скъпо от плащането: диалогово дебъгване, дълга серия дребни промени, демонстрация на живо. Това не е друг модел и не е друго ниво на усилия – това е режим на предоставяне на отговора.

Цената на ускорението при Opus 5 и Opus 4.8 е 10 долара за милион входни токена и 50 за милион изходни, еднакво върху целия прозорец от милион токена; това е по-скъпо от обичайните ставки на Opus. Има неприятна тънкост при първото включване насред диалог: целият вече натрупан контекст се преизчислява по пълната цена на входа на fast режима, затова е по-евтино да го включите в началото на сесията, а не на сотия ход. Ако кредитите свършат по средата на работата, нищо няма да се счупи – Claude Code ще повтори отхвърлените заявки с обичайна скорост и по обичайна цена. В Claude Console кредити няма изобщо: организацията плаща за токените заедно с останалия разход за API. В Amazon Bedrock, Claude Platform на AWS, Google Cloud Agent Platform и Microsoft Foundry режим няма.

Съседни ключове в настройките: `fastMode` го включва постоянно, а `fastModePerSessionOptIn` кара всяка сесия да стартира без него, дори да сте го включвали миналия път.

```
/fast on   # ускорен изход
/fast off  # връщане към обичайния режим
```

#### `/brief`

Режим „само накратко“: максимално сбити отговори без разгърнати обяснения. Аргументи командата няма. Полезно е, когато водите работата сами и от агента ви трябва резултат или кратък факт, а не разбор с примери. Върху обема на самата работа и върху дълбочината на разсъжденията това не влияе – съкращава се само онова, което ви се отпечатва; за дълбочината отговаря `/effort`.

```
/brief  # отговаряй максимално кратко
```

#### `/advisor [модел|off]`

Съветник: по-силен модел подсказва на основния агент в ключови моменти. **[не във всички планове]** нужен е достъп до собственото API на Anthropic – по абонамент или през Console; в Amazon Bedrock, Claude Platform на AWS, Google Cloud Agent Platform и Microsoft Foundry съветник няма и му е нужно включено получаване на флагове за възможности. Смисълът е да не плащате за силния модел през цялата сесия, а да го викате точково. Възможността е експериментална и да се води работен процес върху нея засега е рано.

Вторият модел се намесва не постоянно, а в ключови точки – когато основният агент взема решение, при което грешката струва скъпо. Аргументът е псевдоним или пълен идентификатор на модел; `off` изключва. Без аргумент се отваря избор. Има и флаг за стартиране `--advisor <модел>`, който, между другото, го няма в изхода на `claude --help`.

Разходът на съветника се взема от обичайния лимит на плана – с едно изключение: ако за съветник е назначен Fable 5, работата му се плаща с кредити там, където с кредити се плаща обичайното използване на Fable 5. Докато съгласието за такова таксуване не е дадено чрез `/model fable`, Claude Code просто няма да назначи Fable за съветник.

Без аргумент се отваря същият списък с модели, но в него избирате не работния модел, а помощника: основният модел остава предишният, избраният се включва върху него.

```
/advisor       # избор на съветник от списъка
/advisor opus  # съвети от Opus
/advisor off   # изключване на съветника
```

#### `/plan [open|share|описание]`

Режим на планиране: агентът чете, анализира и предлага план, но нищо не променя – промените във файлове и опасните команди са недостъпни. Излизането от режима става чрез приемане на плана; след него сесията се връща в обичайния режим и започва да го изпълнява. Нужен е там, където цената на погрешно разбрана задача е по-висока от времето за съгласуване: преди голяма преработка, в непознат код, когато промяната се разпростира върху десетина файла.

| Аргумент | Какво прави |
|---|---|
| нищо | Просто влиза в режим на планиране |
| текст на задачата | Влиза и веднага започва да планира това |
| `open` | Отваря файла с текущия план на сесията |
| `share` | Публикува плана като отделна страница, която може да се споделя |

Файловете с планове се намират в `~/.claude/plans/`, ако не е зададен `plansDirectory` – с него се пренасят в хранилището на проекта, за да се обсъжда и версионира планът заедно с кода.

В диалога за приемане на плана има опция „изчисти контекста“: планът остава, а цялото разузнаване, върху което е построен, се изхвърля. Показва се само при `showClearContextOnPlanAccept`, по подразбиране е изключена, и при дълги задачи това е една от най-полезните настройки – изпълнението започва с чист прозорец.

Режимът е достъпен и от самото начало: `claude --permission-mode plan`. И отделно е добре да знаете, че авто режимът по подразбиране действа и вътре в планирането; изключва се с ключа `useAutoModeDuringPlan`.

Готовият план се показва заедно с диалога за приемане и в него трябва да избирате от три варианта. „Yes, and use auto mode“ – приемане и продължаване в авто режим; там, където авто режимът е недостъпен, същият ред се нарича „Yes, auto-accept edits“, а в сесия, стартирана със заобикаляне на разрешенията – „Yes, and switch to BYPASS PERMISSIONS (no further prompts) for this session“. „Yes, manually approve edits“ – приемане, но потвърждаване на всяка промяна ръчно. „No, keep planning“ – оставане в планирането и казване какво да се поправи. Така е описано в документацията.

```
/plan                                      # влизане в режим на планиране
/plan изнеси плащането в отделна услуга    # влизане веднага със задача
/plan share                                # споделяне на плана
```

#### `/goal [условие|clear]`

Задава условие, при което работата се смята за завършена; агентът продължава сам, докато то не се изпълни, вместо да спира след всеки ход. Това променя ритъма: ходът не ви се връща на всяка стъпка и се налага да се намесвате само ако нещо е тръгнало накриво. Смислено е при дълга механична работа – да доведете билда до зелено, да прокарате една и съща промяна през целия проект.

| Аргумент | Какво прави |
|---|---|
| текст на условието | Задава цел |
| `clear`, `stop`, `off`, `reset`, `none`, `cancel` | Сваля активната цел – коя да е от шестте думи |
| нищо | Показва текущата или последната постигната цел |

Условието трябва да е проверимо – команда, състояние на файл, признак в изхода. Размитото „докато не стане добре“ се превръща в безкрайна работа, защото няма с какво да се провери.

Отделна статия от разходите, за която малцина се сещат: докато целта е активна, агентът периодично се събужда и проверява заседнала фонова работа и всяка такава проверка е пълноценен ход с пълния контекст. Честотата се задава от `CLAUDE_CODE_GOAL_CHECKIN_MINUTES`, нула изключва проверките изобщо; от версия 2.1.246 те са не повече от три за цел.

```
/goal докато всички тестове не станат зелени  # работа до изпълнение на условието
/goal                                         # показване на текущата цел
/goal clear                                   # сваляне на целта
```

### Ревю на код и качество

Първите три команди гледат един и същ diff и затова лесно се бъркат, четвъртата изобщо нищо не анализира:

| Команда | На какво гледа |
|---|---|
| `/code-review` | грешки в коректността и чистота на кода; поправя само с `--fix` |
| `/simplify` | само чистота – и веднага прилага намереното |
| `/security-review` | само уязвимости в промените на клона |
| `/diff` | нищо не търси, просто показва промените |

#### `/code-review [ниво|ultra] [--fix] [--comment] [--post|--no-post] [цел]`

Ревю на diff за грешки и опростявания **[Скил]**. Псевдоним: `/review`. Обичайното локално ревю се брои към лимитите на вашия план, а облачният режим `ultra` е **[извън плана]**: в Pro и Max има по три безплатни стартирания, след това се таксува с кредити, обикновено от пет до двадесет и пет долара за ревю, а ако кредитите не са свързани, платеното стартиране просто се блокира. Същият `ultra` е и **[не във всички планове]**: нужен е вход в claude.ai, при външни доставчици и в организации с нулево съхранение на данни го няма.

Най-настройваемата от вградените команди: ниво на усилия, четири флага, цел на ревюто и отделен облачен режим – и всяко се разбира по свои правила. Пълната форма е `/code-review [low|medium|high|xhigh|max|ultra] [--fix] [--comment] [--post|--no-post] [<PR#>|<клон>|<път>|<бележка>]` и всичко в нея е незадължително: голото `/code-review` е валидно извикване.

**Какво търси.** Две различни неща. Грешки в коректността: обърнато условие, off-by-one, достъп до `null`, забравен `await`, премахната проверка, погълната в `catch` грешка, счупени места, които извикват променената функция, класически капани на конкретния език. И чистота: нов код, който повтаря вече съществуващото в хранилището; излишна сложност и мъртъв код; излишна работа като повторни изчисления или последователно изпълнени независими операции; „грешно ниво на решение“, когато се слага кръпка там, където е трябвало да се оправи общ механизъм; преки нарушения на правилата от вашия `CLAUDE.md`.

Грешките в коректността винаги са по-важни от находките за чистота: ако находките са повече от лимита на нивото, първо режат вторите. Самото ревю нищо не поправя, докато не е подаден `--fix`.

**Къде се изпълнява.** Обикновено от фонов агент: сесията не се блокира, находките идват с отделно съобщение. В три случая ревюто заема цялата сесия: ако сте го стартирали повторно, докато предишното още върви; ако сте в неинтерактивния режим `-p` или в SDK; и ако е зададена променливата `CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1`, която изобщо изключва фоновите задачи.

**Кой може да го стартира.** Не само вие. При молба „погледни промените ми“ с обикновен текст агентът ще стартира ревюто сам, а и планирана задача с `/code-review` в промпта също ще сработи. Ако това пречи – да оставите командата въвеждаема, но да забраните на агента и на разписанието да я стартират:

```json title=".claude/settings.json"
{
  "skillOverrides": { "code-review": "user-invocable-only" }
}
```

Облачният режим е изключение: **`ultra` агентът не стартира никога**, нито сам, нито по разписание.

**Редът на аргументите.** Три правила, заради които извикването сработва не както се очаква:

1. `ultra` се разбира само като първа дума. `/code-review ultra --fix` е облачно ревю, а `/code-review --fix ultra` е обикновено локално, в което думата `ultra` е разбрана като цел.
2. Нивото е първата дума, след като от реда са махнати флаговете. Затова `/code-review --fix high` работи и нивото ще е `high`.
3. Флаговете могат да се слагат където и да е: в началото, в края, между нивото и целта. Единственото изключение е правило 1.

И четвърто, отделно: **тази команда „изяжда“ командата, въведена след нея.** Обикновено няколко скила се свързват в едно съобщение и `/write-tests /fix-issue 123` ще зареди и двата. Но `/code-review /fix-issue 123` от версия 2.1.218 разбира `/fix-issue 123` като текст на целта, а не като втора команда. До 2.1.218 е било обратното.

**Нива на усилия.**

| Ниво | Как търси | Находки | Кога да се вземе |
|---|---|---|---|
| `low` | Един проход по diff: без субагенти, без четене на файловете изцяло, без повторна проверка на находките; тестовите файлове не ги гледа | до 4, при част от моделите до 8 | Бърз евтин преглед преди комит |
| `medium` | Осем независими ъгъла на търсене – три за коректност, три за чистота, по един за нивото на решението и за правилата на `CLAUDE.md`, – после проверка на всяка находка | до 8 | Обикновено ревю |
| `high` | Същите осем ъгъла, но проверката е изместена към пълнота: находката остава, ако не е могла да бъде опровергана | до 10 | Когато пропусната грешка струва по-скъпо от излишния шум |
| `xhigh` | Десет ъгъла по осем кандидата, проверка и отделен краен проход „какво сме пропуснали“ | до 15 | Голям или рисков diff |
| `max` | Същото като `xhigh`, с максимален упор върху пълнотата | до 15 | Преди издание, миграция – всичко, което трудно се връща |
| `ultra` | Не ниво, а отделен режим: мултиагентно ревю в облака | – | Цял pull request, който искате да проверят чужди очи |

Числата в тази таблица са снети от бинарния файл: официалната документация описва нивата качествено – „ниските връщат най-уверените находки, високите разширяват обхвата и могат да включват по-малко уверени“, – а колко ъгъла на търсене има и какъв е таванът на находките, не публикува никъде.

Точният конвейер зависи от модела на сесията, затова таблицата е за смисъла на нивата, а не за гарантиран брой агенти. При Opus 5 `medium` и `high` засега се свеждат до един внимателен проход с лимит от петнадесет находки, а разликите започват от `xhigh`; при Sonnet 5 на нивата `high`, `xhigh` и `max` броят на търсещите агенти се подбира според размера на diff – от два до осем.

Отделна такса за горните нива няма, но всеки търсещ агент води свой контекст, затова `xhigh` и `max` харчат лимита на плана забележимо по-бързо от `low`. Да въртите `max` за всяка дребна промяна е най-простият начин да останете без седмичен лимит до сряда.

**Запомняне на нивото.** Ако нивото не е указано, взема се онова, което сте въвели последния път: то живее между сесиите и в началото на отчета за това ще кажат с ред от вида „използвам high, нивото от миналия път“. Две изключения: ниво, подадено в неинтерактивно стартиране `-p`, нищо не запомня, а `ultra` нито чете запомненото ниво, нито го променя. Ако не сте въвеждали нито веднъж, взема се нивото на усилия на текущата сесия. Въведеното ниво заедно с това задава усилията на модела за хода, включително надолу: `/code-review low` в сесия на `xhigh` ще ги понижи.

Печатна грешка не чупи извикването: при `/code-review higher` ще получите предупреждение, че стойността не е разпозната, и предишното или подразбиращото се ниво. Съкращението `med` се приема като `medium`.

**Флагове.**

| Флаг | Къде работи | Какво прави |
|---|---|---|
| `--fix` | локално и с `ultra` | След отчета прилага находките към работното дърво |
| `--comment` | локално, ако целта е pull request в GitHub | Публикува всяка находка като отделен коментар към реда |
| `--post` | само `ultra`, хранилище в github.com | Публикува резултата с един обикновен коментар от вашия акаунт |
| `--no-post` | само `ultra` | Маха предложението за публикуване от прозореца за стартиране – това така или иначе е поведението по подразбиране |

`--fix` поправя намереното направо в работното дърво – и грешките, и чистотата. Находката се пропуска, ако промяната променя замисленото поведение, изисква промени далеч извън прегледания diff или изглежда като фалшиво задействане; накрая ще ви кажат какво са пропуснали и защо. При `ultra` промените се прилагат локално в момента, в който облакът върне резултата.

`--comment` изисква целта да е pull request. Ако целта не е такава, флагът се игнорира, находките просто се отпечатват и агентът ще ви каже за това. Коментарите тръгват през интеграцията с GitHub, а ако такава в сесията няма – през `gh api`.

`--post` не е същото като `--comment`: един общ коментар вместо забележки по редове и само за облачното ревю. В интерактивна сесия прозорецът за стартиране все пак пита за потвърждение, в неинтерактивен режим публикува веднага по флага. Подаден към обикновеното локално ревю, се игнорира – ще ви напомнят, че там публикува `--comment`.

`--no-post` е нужен, за да не виждате изобщо предложението за публикуване. Да се подават и двата едновременно е безсмислено: командата чете само `--post`, така че `--post --no-post` все пак ще предложи публикуване.

**Целта на ревюто.** Без цел се ревюира текущата работа: комитите на клона над неговия upstream плюс незакомитнатите промени. Затова командата има смисъл и преди комит.

В локалното ревю целта се предава на модела като низ и той сам решава какво е: номер на pull request, име на клон, път към файл или папка – или просто пожелание накъде да погледне най-напред. При `ultra` целта се разбира строго:

| Какво подадете | Какво ще се случи |
|---|---|
| нищо | Ревюира се текущият клон спрямо базовия |
| `1234`, `#1234`, `PR 1234`, връзка към `/pull/1234` | Зарежда се и се ревюира този pull request |
| име на съществуващ клон | Взема се като базов, diff се смята спрямо него |
| всичко останало | Записва се като бележка към ревюто: облачният агент не я вижда и така или иначе ревюира diff на клона, но когато находките се върнат, ще бъдат свързани с вашата молба |

**Ревю в облака: какво е нужно, колко струва и къде е таванът.** `ultra` стартира фонов агент в Claude Code в уеб: той клонира хранилището в облачен пясъчник (sandbox), прокарва върху diff мултиагентно търсене и изпраща находките с известие във вашата сесия. Отнема минути, през цялото това време можете да работите нататък.

Изискват се git хранилище и GitHub remote, акаунт в claude.ai със свързан GitHub, а за частно хранилище – инсталирано върху собственика приложение на Claude. Недостъпно е при външни доставчици, при изключени незадължителни заявки, в организации с нулево съхранение на данни и при забрана от страна на организацията. Важна подробност: когато режимът е недостъпен, **`/code-review ultra` не пада, а тихо изпълнява обикновено локално ревю** – ако сте очаквали облачното, струва си да се уверите, че наистина е стартирало.

Таванът на diff е до петстотин променени файла и осем хиляди променени реда. Твърде голям pull request се отхвърля, а в отказа се посочват действащите лимити, размерът на вашия diff и най-едрите файлове; празен diff също се отхвърля.

Цена: в Pro и Max по три безплатни стартирания – дават се на акаунта еднократно и не се подновяват, – а в Team и Enterprise безплатни няма изобщо. Нататък – от кредитите, обикновено от пет до двадесет и пет долара за ревю в зависимост от размера на промените. Стартирането се брои от момента на старта на облачната сесия: спряно или паднало ревю безплатното стартиране все пак го харчи, а платеното се таксува само за отработената част. Ако кредитите не са свързани, платеното стартиране просто се блокира.

**Какво потвърждавате преди старта.** Платено облачно стартиране не тръгва тихо: първо ви показват прозорец с оценка на цената и искат да се съгласите с таксуването на кредити – веднъж за разговор. Там, ако е подаден `--post`, решавате дали да публикувате резултата с коментар в pull request или да оставите находките само при себе си. Докато не потвърдите, облачната сесия не стартира.

**От CI.** От версия 2.1.218 облачното ревю се стартира неинтерактивно:

```bash
claude -p '/code-review ultra'
```

Командата стартира ревюто, отпечатва връзка за проследяване и не чака резултата. Но ако ревюто трябва да таксува кредити, стартирането ще спре: потвърждаването на плащането изисква интерактивна сесия. За такъв случай има отделна подкоманда, самият факт на стартиране на която се смята за ваше съгласие за таксуване:

```bash
claude ultrareview                       # облачно ревю на текущия клон
claude ultrareview 1234 --post           # ревю на PR, резултатът – коментар в него
claude ultrareview --json                # сурови находки вместо отчет
claude ultrareview dev --timeout 60      # спрямо клона dev, чакане до час
```

Кодът на изход е 0, ако ревюто е завършило (с находки или без), и 1, ако не е могло да бъде стартирано. `--timeout` по подразбиране е тридесет минути.

Каноничната форма е `/code-review ultra`; `/ultrareview` е нейният псевдоним, достъпен не за всички акаунти, и цялата възможност е отбелязана като изследователска. В статиите често пишат обратното, сякаш основната команда е `/ultrareview`.

**В GitHub Actions.** Ревюто има отделен живот в CI и там се настройва не с флагове, а с файл. В корена на хранилището се слага `REVIEW.md`, който задава правилата: кои пътища и клонове да се пропускат, кои категории находки да не се показват, какво да се смята за важно, как да се държи при повторно ревю на един и същ pull request.

Находките се делят на три нива: важни, дребни забележки и съществували в кода още преди тези промени. Нарушенията на вашите правила от `CLAUDE.md` попадат в дребните забележки. Проверката винаги завършва с неутрален статус и затова никога не блокира сливането сама – но с последния ред отпечатва брояч на находките в JSON от вида `{"normal": 2, "nit": 1, "pre_existing": 0}`, по който можете да поставите собствена бариера във вашия си пайплайн.

Какво ще дойде в отговор, зависи от режима: обикновеното ревю изпраща отчет с отделно съобщение, `--fix` добавя към него промени в работното дърво, `--comment` отвежда находките с коментари в pull request, а `ultra` първо ще поиска потвърждение в прозореца за стартиране и едва тогава ще даде връзка към облачната сесия.

```
/code-review                                   # текущите промени, ниво като миналия път
/code-review high --fix                        # по-дълбоко и веднага поправяне на намереното
/code-review medium --comment 1234             # ревю на PR 1234 с коментари направо в него
/code-review ultra 1234 --post                 # облачно ревю на PR, резултатът – коментар
```

#### `/simplify [цел]`

Намира в променения код опростявания и веднага ги прилага **[Скил]**. Това е почистване след себе си, когато кодът вече работи: грешки командата не търси изобщо, затова минава по-бързо от ревюто – но и да го замени не може. Прибягвате към нея, когато промяната е успяла да се разрасте: появили са се почти еднакви парчета, свои помощници върху вече съществуващите, излишни междинни слоеве.

Гледа същия diff като `/code-review`, но търси само чистота и го прави с четири паралелни агента: преизползване на вече написани помощници, опростявания, ефективност и дали това е правилното ниво на абстракция. Грешки не търси по принцип – това е разделение на труда, а не недоработка. И за разлика от ревюто, **веднага прилага** намереното. Аргументът е незадължителна цел: път, папка или номер на pull request.

Отделно не се таксува, но четири агента са четири контекста наведнъж, така че лимита на плана командата го харчи осезаемо по-бързо от единичен проход.

Историческа клопка: до версия 2.1.147 днешната `/code-review` се наричаше `/simplify` и прилагаше промените по подразбиране. Стар скрипт, който е викал `/simplify` заради търсене на грешки, днес прави съвсем друго.

Да избирате по хода няма да се налага: командата нищо не пита, а в отговор идва списък на приложените опростявания – промените към този момент вече са в работното дърво.

```
/simplify                                # целият променен код
/simplify src/payments                   # само тази папка
```

#### `/security-review`

Проверява промените на клона за уязвимости. Аргументи няма. Това е трети поглед върху същия diff, но с друга оптика: не „работи ли“ и не „написано ли е спретнато“, а какво оттук може да се изтегли или счупи отвън. Има смисъл да я викате, преди клонът да замине към общото хранилище – особено ако промяната е докосвала автентикация, обработка на потребителски вход или тайни.

Търси инжекции, проблеми с оторизацията и автентикацията, течове на данни, небезопасна работа с тайни и с входни данни.

Единственото изискване, в което се спъват: **нужен е remote с име `origin`** – diff се смята спрямо неговия основен клон. Без него командата пада с git грешка за нееднозначен аргумент и това изглежда загадъчно.

В отговор идва списък на намереното: мястото в кода, характерът на проблема и с какво е опасен.

```
/security-review                         # уязвимости в промените на клона
```

#### `/diff`

Интерактивен преглед на незакомитнатите промени. Аргументи няма. Нищо не анализира, това е прегледник: незакомитнатите промени и, което е по-полезно, diff за всеки ход на агента поотделно. Полезен е, когато агентът е свършил много неща за няколко хода и трябва да се разбере на коя точно стъпка е свърнал накриво – тоест нещо, което си струва да се ползва преди `/rewind`, а не след него.

Вътре избирате какво да гледате: цялата незакомитната работа наведнъж или един конкретен ход на агента. Излизането от прегледника ви връща в същата сесия и нищо в кода не променя – връщането живее в `/rewind`, тук го няма.

```
/diff                                    # преглед на незакомитнатото
```

### Разработка и работни процеси

`/run` и `/verify` постоянно се бъркат: и двете са за „проверка на живо“, но отговарят на различни въпроси.

| Команда | На какъв въпрос отговаря |
|---|---|
| `/verify` | Прави ли конкретната промяна онова, което е замислено |
| `/run` | Как се държи приложението като цяло, ако го вдигнете както обикновено |

#### `/run`

Стартира приложението на проекта и проверява промяната на живо, а не само с тестове. **[Скил]** Прибягва се до нея, когато по diff нищо не се разбира: сменил се е екран, поведение на форма, изход на команда – просто трябва да видите работещото приложение. Да не се бърка с `/verify`: тя отговаря за една конкретна промяна, а `/run` вдига всичко както си е.

Става дума за приложението като цяло: да се вдигне така, както се вдига в този проект, и да ви се даде да го видите. За да знае как точно, е нужен скил за стартиране – създава го `/run-skill-generator`, веднъж за проект. Без него `/run` ще се опита да налучка по типа на проекта и при нестандартен билд ще налучка зле.

След извикването вървят обичайните стъпки на билд и старт – записаните в скила или изведени от типа на проекта, – а нататък гледате самото приложение: вдигнало ли се е и прави ли онова, заради което е вдигано.

```
/run  # стартиране на приложението и гледане с очите
```

#### `/verify`

Потвърждава, че промяната работи: билд, стартиране, наблюдение на поведението. **[Скил]** Прибягва се до нея веднага след промяна, когато е важно да не повярвате на diff, а да видите резултата. Проверява се именно промяната, а не приложението като цяло – за второто има `/run`.

Логиката е проста: ревюто проверява, че diff се **чете** правилно, `/verify` – че **работи** правилно.

От версия 2.1.200 командата умее да запише намерената рецепта за проверка в собствен скил `.claude/skills/verify/SKILL.md` и тогава в корена на хранилището той замества вградения – тоест веднъж сте разбрали как се проверява този проект и нататък това работи за всички.

Важна промяна: **от версия 2.1.215 `/verify` се стартира само от вас.** Преди агентът можеше да я извика сам. Същото се случи с `/deep-research` в 2.1.218. Ако сте чели статия, където пише, че агентът ще се провери сам, тя е остаряла.

Проверката върви докрай сама: билд, стартиране, наблюдение на поведението, – а накрая получавате заключение дали всичко е наред и какво точно е било гледано. Ако рецепта за проверка в хранилището още не е имало, попътно ще ви предложат да я запишете.

```
/verify  # билд, стартиране, убеждаване, че работи
```

#### `/run-skill-generator`

Създава скил, който умее да стартира приложението на този проект – върху него после работи `/run`. **[Скил]** Командата разбира как тук всичко се билдва и стартира и записва намерената рецепта в скил, който се намира в хранилището и работи за всички.

Прави се веднъж за проект.

Работата тук не е мигновена: приложението наистина се вдига от нулата, като се запомня кои команди за инсталиране, променливи на средата и скрипт за стартиране са сработили. Резултатът е файл със скил в хранилището, а не текст в терминала.

```
/run-skill-generator  # научаване на проекта на командата /run
```

#### `/batch <инструкция>`

Планира мащабна промяна и я изпълнява паралелно в 5–30 изолирани работни копия, всяко от които отваря свой pull request. **[Скил]** Нужна е там, където една и съща промяна трябва да се внесе на десетки места и всяко място е самостоятелно парче работа. За една промяна в два файла е излишна: разходите за fan-out ще изядат цялата печалба.

Най-тежката от вградените команди и единствената, която по подразбиране ражда десетки агенти. Инструкцията първо се превръща в план – списък с конкретни места, които трябва да се поправят, – а после за всяко място се стартира свой агент в свое изолирано работно копие на git и всеки отваря отделен pull request.

Ключовото тук е изолацията. Агентите променят файлове паралелно и без отделни работни копия биха си пречили. Оттук и изискванията: git хранилище, чисто дърво и настроен `gh`, иначе няма с какво да се отварят pull request.

Броят на агентите е от пет до тридесет и се извежда от плана, а не се задава от вас: колкото места са намерени, толкова агенти, в рамките на тавана. Ако планът се получи за две места, fan-out не е нужен и командата ще го каже.

Отделна такса за нея няма, но лимита на плана го харчи многократно: двадесет агента са двадесет сесии, всяка със свой контекст.

Добрата инструкция е онази, в която границите на всяко място са очевидни и промените не са свързани помежду си. Лошата е „рефакторирай проекта“: планът ще се получи от размити пунктове, а тридесет агента независимо ще измислят тридесет различни архитектури.

Върху поведението на fan-out влияят настройките `worktree`: `symlinkDirectories` пести място на диска, ако проектът има тежки зависимости, `sparsePaths` ускорява изтеглянето в големи монорепозитории, `baseRef` определя дали да се разклонява от отдалечения основен клон или от текущото локално състояние.

Редът е такъв: първо ви показват плана и чакат съгласие – това е моментът, в който се решава дали местата са толкова, колкото сте очаквали. След одобрение агентите отиват да работят на фон, а връзките към отворените pull request-и се появяват по мере готовност.

```
/batch прехвърли всички контролери към новия клиент  # fan-out от изолирани агенти, всеки със свой PR

/batch разнеси общите DTO по модулите, които ги използват  # ако местата са малко, fan-out не е нужен – командата ще го каже
```

#### `/debug [описание]`

Включва дебъг логове за сесията и помага да се разбере проблемът. **[Скил]** Полезна е, когато не е ясно чия е бедата – ваша или на самия агент: в подробните логове се вижда какви инструменти са извиквани и с какво са отговорили. Логовете се включват до края на сесията, на следващата не се пренасят.

Описанието е незадължително – с него веднага казвате какво точно ловите.

Без описание нещата се ограничават до включване на подробните логове, нататък работите както обикновено. С описание командата веднага се заема с разбора на посочения проблем, опирайки се на онова, което ще се появи в тези логове.

```
/debug                                           # включване на дебъг логове

/debug пада само на CI, локално е зелено         # същото плюс описание на проблема
```

#### `/fewer-permission-prompts`

Прегледва транскриптите, намира често срещани безопасни извиквания и сглобява от тях списък с разрешения. **[Скил]** Смисълът е да престанете да потвърждавате по десет пъти на ден едно и също безобидно четене. Командата гледа вашата собствена история, а не общ списък, затова разрешенията излизат за конкретния проект.

Промяната се записва в настройките на проекта, тоест ще действа за всички, които работят с това хранилище.

Резултатът е предложен списък с разрешения, подреден по онова, което е потвърждавано най-често; вие избирате – да го приемете изцяло или да зачеркнете излишното, преди да легне в настройките на проекта.

```
/fewer-permission-prompts  # съставяне на списък с разрешения от историята
```

#### `/commit [пожелания]`

Прави комит: гледа статуса и diff, пише съобщение по приетия формат. **[Скил]** Форматът на съобщението се извежда от историята на комитите на това хранилище, а не от общи правила – в чужд проект комитът ще изглежда като съседните. Полезна е точно с това, че сваля две скучни стъпки: да решите какво влиза в комита и да формулирате какво, всъщност, сте направили.

Аргументът не са флагове, а пожелания с обикновен текст; това важи и за `/pr`. Пожеланията влияят върху онова, което ще попадне в комита, и върху това как ще бъде написано съобщението.

Какво ще попадне в съобщението на комита като атрибуция, се задава с обекта `attribution` с полета `commit` и `pr`, където празният низ я маха напълно. Вградените инструкции за комитите могат да се изключат изцяло чрез `includeGitInstructions: false` – тогава агентът ще ползва само вашите правила.

Преди създаването на комита се вижда какво е подбрано за него и с каква формулировка – тук се решава дали ви устройват и двете. С пожеланията от втория пример съставът на комита се стеснява до файловете на схемата, останалото остава в работното дърво недокоснато.

```
/commit  # комит със съобщение по формата на проекта

/commit само промените в схемата, останалото не пипай  # в комита ще влязат само файловете на схемата
```

#### `/pr [пожелания]`

Отваря pull request: създава клон, изпраща го (push) и създава описание чрез `gh`. **[Скил]** Описанието се съставя по онова, което реално е в diff, а не по вашия преразказ. Трите стъпки на ръка отнемат няколко минути и обикновено именно на описанието се пести; тук то се пише само.

Клонът се създава, ако още сте на основния. С пожелания се задават чернова, ревюъри, форма на описанието.

Стъпките вървят подред – клон, push, създаване на заявката чрез `gh`, – и накрая в ръцете ви е връзка към отворения pull request. Пожелания от рода на „като чернова“ променят начина, по който ще се отвори заявката, но не и реда на стъпките.

```
/pr  # клон, push, pull request с описание

/pr като чернова, не назначавай ревюъри  # същото, но заявката ще се отвори като чернова
```

#### `/commit-push-pr`

И трите стъпки наведнъж: комит, push, pull request. **[Скил]** Същото като `/commit` и `/pr` подред, но без паузи между тях – за случая, когато работата очевидно е свършена и няма какво да се обсъжда. Ако искате да погледнете комита, преди да замине, по-добре е с две команди.

Има особеност: **опасните флагове на `git` и `gh` не се одобряват автоматично.** `--force`, `--amend`, `--no-verify` все пак ще поискат потвърждение, дори да имате щедри права. Направено е нарочно: веригата от три стъпки се изпълнява бързо и човек не успява да забележи, че някъде по средата се пренаписва историята.

И трите стъпки минават без спиране и накрая остава връзка към заявката. Веригата може да прекъсне точно едно нещо – опасен флаг по пътя: на него все пак ще ви попитат дали да продължат.

```
/commit-push-pr  # и трите стъпки наведнъж
```

#### `/update-config`

Променя настройките: хукове, права, променливи на средата – с редактиране на `settings.json` вместо вас. **[Скил]** Главният ѝ случай е поведение от вида „всеки път, когато…“: такова нещо умее само хук, с молби и с памет това не се постига, защото ги изпълнява не моделът, а самата програма. Кажете с думи какво трябва да се случва – командата ще разбере в кой файл с настройки да го запише и в какъв вид.

Настройките са проектни и лични и това са различни файлове: проектните ги вижда всеки, който работи с хранилището, личните – само вие. Ако промяната засяга вашите навици, а не общия ред на работа, кажете го веднага.

Преди да се промени нещо, ще ви обяснят каква настройка ще се появи и в кой файл – и ако е избран погрешен файл, това е точно моментът, в който си струва да се намесите.

```
/update-config добави хук за форматиране след промени
```

#### `/claude-code-docs [въпрос]`

Отговори за самия Claude Code: възможности, настройки, SDK, Claude API, приложението за Slack. **[Скил]** Отговаря по документацията, а не по паметта на модела, – а това са различни неща, защото програмата се променя от версия на версия по-бързо, отколкото се обновяват знанията на модела. Питайте по-добре с човешка фраза, както бихте попитали колега.

В отговор идва разбор по документацията с връзки към нейните раздели – по тях е удобно да се провери, че отговорът не е измислен.

```
/claude-code-docs как да ограничим достъпа на агента до папка
```

#### `/claude-in-chrome`

Разрешава работа във вашия Chrome: кликане, попълване на форми, четене на конзолата. **[Скил]** **[не във всички планове]** – изисква се вход в акаунт claude.ai: с API ключ и през Amazon Bedrock, Google Cloud и Microsoft Foundry разширението е недостъпно. Работата върви във вашия истински браузър, с вашите раздели и сесии, – затова е подходяща там, където трябва да се проверява не кодът, а живата страница: да се възпроизведе бъг в интерфейса, да се мине през форма, да се видят грешките в конзолата.

Достъпът се дава по сайтове и се настройва в самото разширение: на страница, която не сте разрешили, агентът няма да отиде.

След извикването агентът се свързва с вашия браузър и нататък работи с разрешените раздели. Ако нужният сайт не е сред разрешените, изборът е прост: да му дадете достъп в разширението или да се откажете от тази проверка.

```
/claude-in-chrome  # разрешаване на работа в браузъра
```

#### `/plugin-types [папка]`

Генерира типове на входните данни на свързаните MCP инструменти. Командата чете описанията на инструментите и ги разгръща в типове, така че в кода на плъгина извикванията да се проверяват от компилатора, а не да се налучкват по памет. Аргументът е папката на плъгина, за който да се генерира. Нужна е при разработка на собствен плъгин; в обикновената работа с проект няма да ви потрябва.

Тук няма какво особено да се гледа: резултатът от командата са файлове с типове вътре в указаната папка на плъгина.

```
/plugin-types ./my-plugin  # типове на MCP инструментите за плъгина
```

#### `/workflow-authoring`

Справочник по писане на скриптове за воркфлоу. **[Скил]** Разказва от какво се състои скриптът, как е устроено възобновяването след срив и в какво обикновено се спъват. Чете се, преди да пишете свой воркфлоу, а не по време на изпълнението му.

Самото стартиране на воркфлоу не разрешава.

В отговор идва самата справка – устройство на скрипта, възобновяване, типични грешки и разгледани примери, – след което можете да сядате да пишете своя.

```
/workflow-authoring  # как се пишат скриптове за воркфлоу
```

#### `/claude-api [migrate|upgrade|prompt-audit|managed-agents-onboard|cost-optimize]`

Помощ по Claude API и SDK. **[Скил]** Единствената команда в тази група с фиксиран набор от аргументи. Нужна е, когато пишете код, който сам ходи към Claude: идентификатори на модели, параметри, стрийминг, извикване на инструменти, кеширане – всичко това се сверява с документацията, а не с паметта на модела.

Аргументът избира сценарий: без него е обща справка, с него – конкретна работа по вашия код.

| Аргумент | Какво прави |
|---|---|
| без аргумент | Обща помощ по Claude API и SDK: параметри, стрийминг, извикване на инструменти, кеширане |
| `migrate` | Миграция на кода към нов модел: какво да се промени в идентификаторите, параметрите и очакванията |
| `upgrade` | Преминаване към нова мажорна версия на клиентската библиотека; от 2.1.236 |
| `prompt-audit` | Намиране в промптовете, скиловете и описанията на инструментите на указания, писани за стари модели, и предлагане на поправка с diff; от 2.1.221 |
| `managed-agents-onboard` | Онбординг към сървърни агенти с управляем пясъчник |
| `cost-optimize` | Разбор на разходите за API и какво да се прави с тях; от 2.1.247 |

Скилът се включва и сам, без команда: ако в кода на проекта има импорт на официалната библиотека на Anthropic, той се активира при задачи, които я засягат.

С аргумент командата първо чете вашия код и се връща със списък на местата и предложени промени – да ги приемете всички или една по една, решавате вие.

```
/claude-api migrate       # миграция към нов модел

/claude-api prompt-audit  # намиране в промптовете на инструкции за стари модели
```

#### `/deep-research <въпрос>`

Fan-out от уеб търсения в множество източници, проверка на фактите и отчет с връзки. **[Воркфлоу]** Прибягва се до нея, когато едно търсене не стига: въпросът е спорен, източниците си противоречат или е нужен не първият попаднал отговор, а сверен. Търсенето върви по няколко независими линии, намереното се съпоставя помежду си и в отчета се вижда на какво точно се опира заключението.

От версия 2.1.218 се стартира само от вас – преди агентът можеше да я извика сам.

Това е динамичен воркфлоу: стартират се много агенти и едно изпълнение изяжда лимита на плана забележимо по-бързо от обикновена сесия. В плана Pro динамичните воркфлоу първо се включват с реда Dynamic workflows в `/config`.

Първо ще попитат за разрешение да се стартира воркфлоуът – и това е единственият ви избор по хода на работата. Нататък всичко върви на фон, сесията остава свободна, за напредъка при желание може да се следи чрез `/workflows`, а накрая идва отчет с връзки; твърденията, които не е могло да се проверят, са отбелязани като непроверени, а не се представят за факт.

```
/deep-research с какво се различават подходите към идемпотентността в опашките
```

### Субагенти, фонови задачи, автоматизация

#### `/list-agents`

Показва всички, на които може да се пише директно от сесията: субагентите, които сте стартирали, тиймейтите, другите сесии на Claude Code на тази машина и облачните. Името в списъка е адресът: копирате го и изпращате съобщение точно на този агент. До списъка се стига не от любопитство, а когато трябва да разберете кой още е жив и как да се обърнете към него. Псевдоним: `/peers`.

Тиймейтите (екипите от агенти) са изключени навсякъде по подразбиране и се включват с променливата `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` – докато я няма, редове с тях в списъка няма да има. И трябва да помните цената: екип от агенти харчи около седем пъти повече токени от обикновена сесия, защото всеки тиймейт има свой контекстен прозорец и харчи, докато не приключи.

Командата само отпечатва списък и не предлага нищо за избиране: името на нужния агент го взимате оттам сами и после го поставяте в съобщението.

#### `/tasks`

Показва всичко, което работи до диалога: фоновите задачи, стартираните процеси, състоянието им и откога вървят. Оттук те се и управляват – това е единственото място, където се виждат наведнъж всички стартирани билдове и изпълнения на тестове. Върши работа, когато са няколко и не е ясно кои още са живи и кои отдавна са паднали. Псевдоним: `/bashes`.

В списъка избирате конкретен ред: после можете да видите изхода на тази задача или да я спрете, без да излизате от диалога и без да търсите процеса в системата.

#### `/daemon`

Управлява фоновите услуги на Claude Code – тези, които работят извън вашия диалог: асистентите, планираните задачи и отдалеченото управление. Тук се идва, когато нещо от това трябва да се включи, да се изключи или да спре да се задейства. Обърнете внимание: част от тези услуги – планираните задачи и отдалеченото управление – живеят само при влизане в акаунт в claude.ai, а с API ключ просто няма да ги има.

Изборът тук е между услуги, а не между задачи: намирате нужния ред и превключвате състоянието му, всичко останало става от само себе си.

#### `/workflows`

Историята на воркфлоу – тези изпълнения, при които задачата се разделя на много агенти и те работят паралелно. Показва и текущите, и приключилите: колко агента, на коя стъпка, с какво е свършило. Оттук изпълнението се слага на пауза и се възобновява – това е единственото място, където върху дълго изпълнение може да се повлияе, без да се убива цялото. Да не се бърка с фоновите задачи: те са за процеси и команди, а тези – за мултиагентни изпълнения.

Едно такова изпълнение изяжда осезаемо повече токени от същата работа в обикновен диалог – агентите са много, всеки има свой контекст. Таксува се като обикновен разход, отделна сметка няма. Когато в изпълнението има повече от 25 агента или прогнозата надхвърля 1,5 милиона токена, Claude Code предупреждава предварително; в режим ultracode предупреждението не се показва – като го включите, вече сте се съгласили с големи изпълнения. На плана Pro самите воркфлоу първо се включват в `/config`.

#### `/loop [интервал] [промпт]`

Повтаря промпт или команда през интервал; без интервал темпото се избира само. Псевдоним: `/proactive`. **[Скил]**

Командата приема две неща поредно: незадължителен интервал и това, което да се повтаря. Повтарят се както обикновен промпт, така и слеш команда.

| Какво сте подали | Какво ще се случи |
|---|---|
| `<интервал> <промпт>` | Промптът се изпълнява по разписание с този интервал |
| `<интервал> /команда` | Същото, но се повтаря слеш команда |
| `<промпт>` | Интервал не е зададен: агентът сам решава кога да се събуди следващия път |
| нищо | Автономен цикъл: агентът сам избира и задачата, и темпото |

Интервалът се пише с човешко съкращение: `5m`, `30m`, `1h`. Режимът без интервал трябва да се разбира буквално: агентът избира паузата според това, което чака. Билд, който върви осем минути, ще чака с една пауза, а не с осем проверки през минута.

Капанът е точно един, но скъп: цикъл, който се събужда всяка минута, за да провери фонова задача, почти винаги е излишен. За завършването на фонова работа ще ви съобщят и без това, а всяко събуждане е пълноценна заявка с целия контекст.

Какво вече върви и с каква периодичност, показва `/usage`: отделна команда за това, `/loops`, в билда 2.1.251 е изключена.

Извикването създава цикъл и веднага връща управлението: после той се събужда сам, а всяко събуждане изглежда в сесията като обикновена заявка.

```
/loop 5m /code-review low               # на всеки пет минути – бърз преглед
/loop 1h провери дали не са се появили нови паднали тестове и поправи очевидното
/loop проверявай дали билдът не се е счупил  # без интервал: темпото ще се избере само
```

#### `/schedule [описание]`

Създава, обновява и стартира агент, който работи в облака по разписание. **[не за всички планове]** – нужно е влизане в акаунт в claude.ai: с ключ за Console API, под профил на Anthropic и през Bedrock, Google Cloud и Foundry командата я няма, там най-близкият заместител е `/loop`. **[извън плана]** – самите изпълнения се броят към обикновения лимит на плана, но акаунтът има дневен таван на броя изпълнения: когато опрете в него или в лимита на плана, продължаването е възможно само със свързани кредити, а без тях излишните изпълнения се отхвърлят до нулирането на прозореца. Псевдоним: `/routines`. **[Скил]**

Разликата от `/loop` е мястото на изпълнение. `/loop` работи във вашата сесия, на вашата машина, докато тя е отворена. `/schedule` създава задачата в облака: изпълнява се по разписание независимо от това дали лаптопът ви е включен.

Аргументът е описание с думи, от което се извеждат и разписанието, и задачата, и намерението: командата умее не само да създава, но и да обновява, да показва, да стартира извън разписанието и да изтрива. Останалите изисквания са същите като при всичко облачно: свързан GitHub и липса на забрана от организацията – при Team и Enterprise собственикът може да изключи разписанията за всички. Средата по подразбиране се взима от настройката `remote`. Цялата функционалност е отбелязана като изследователска, тоест ще се променя.

За разходите трябва да помните едно: планираната задача се събужда и изпраща пълния контекст, дори когато сте пред компютъра и сте заети с друго. Това е най-незабележимата позиция в разходите от всички.

Какво ще се окаже на екрана, зависи от това, което сте поискали: и четирите извиквания по-долу са една и съща команда, която разбира вашето описание.

```
/schedule всяка сутрин в 9 събирай отчет за паднали тестове    # създаване на задача
/schedule покажи ми планираните задачи                         # какво вече е заведено
/schedule стартирай сутрешната справка веднага                 # изпълнение извън разписанието
/schedule изтрий задачата за зависимостите                     # изтриване
```

#### `/autofix-pr [промпт]`

Стартира облачна сесия, която следи pull request-а на текущия клон и сама пуши поправки – например оправя паднал билд в CI. **[не за всички планове]** – работи през Claude Code в уеб, а за него е нужно влизане в claude.ai: с API ключ и през Bedrock, Google Cloud и Foundry облачни сесии няма. Незадължителният аргумент стеснява мандата: какво може да се поправя и какво не бива да се пипа. Управлението се връща веднага – после сесията живее сама в облака и да я гледате трябва там.

```
/autofix-pr                                           # следи PR-а и оправяй падналия CI
/autofix-pr оправяй само линтера, логиката не пипай   # същото, но с ограничение
```

### Артефакти, документи и дизайн

Артефактът е публикувана в claude.ai страница, която може да се отвори, да се пощрака по нея и да се даде на колегите за преглед. Почти всичко по-долу са вградени скилове и **наборът зависи от акаунта**: част от тях се включват само за определени абонаменти и организации.

Публикуване има на Pro, Max, Team и Enterprise: на Team е включено веднага, на Enterprise го включва собственикът на организацията, а при CMEK, HIPAA или забрана за съхранение на данни е затворено напълно. Нужна е сесия с влизане в claude.ai – с API ключ, токен на шлюз и данни за достъп на Bedrock, Google Cloud и Foundry страницата няма да се публикува. Отделно артефактите не се таксуват: генерирането на страница харчи изходни токени като всеки друг отговор.

В официалния справочник на командите от тази група има само `/artifacts`, `/design`, `/design-login` и `/design-sync`, а останалите петнайсетина **[няма в документацията]** – нито в чейнджлога, нито в търсенето, така че по-долу е това, което има в билда, а не това, което някъде е обещано.

#### `/artifacts`

Показва вашите публикувани артефакти и тези, които са споделени с вас: име, връзка, кога са обновявани. **[не за всички планове]** – като всичко в тази група, изисква сесия с влизане в claude.ai. Главното приложение е практическо: да намерите връзката към страница, направена в минала сесия – без нея Claude Code ще публикува нова вместо да обнови старата. Освен това това е инвентар: вижда се какво вече е публикувано и не се ли е изгубило нещо.

Списъкът е интерактивен: на избрания ред артефактът или се отваря в браузъра, или връзката му се копира в буфера – за това не е нужно да напускате терминала.

#### `/prototype`

Превръща идеята в работещ прототип – една самодостатъчна страница, която може да се отвори, да се пощрака и да се покаже. **[не за всички планове]** – публикуването изисква влизане в claude.ai. Взима се, когато да спорите с думи излиза по-скъпо, отколкото да погледнете: екран на интерфейс, поток от няколко стъпки, чернова на лендинг. От дизайнерските команди по-долу се отличава с това, че прави работеща вещ, а не картинка.

Предварително нищо не се пита: описвате идеята с думи, после работата върви до готова страница и накрая остава връзка към нея.

```
/prototype страница за избор на план: три плана, превключвател месец-година, изчисляване на отстъпката
```

#### `/doc`

Публикува работен документ, който се редактира направо на страницата: бележка, наръчник, инструкция за екип. **[не за всички планове]** – нужно е същото влизане в claude.ai. Смисълът е, че документът не остава в разговора: има адрес, може да се отвори, да се допише и да се сподели връзката. Тук си струва да посегнете, когато резултатът е нужен на хора, а не само на вас в терминала.

Какъв документ е нужен, се казва направо в командата; в отговор идва адресът на публикуваната страница, а после тя се редактира или на самата страница, или с молба към агента.

```
/doc събери от решенията в този разговор кратък наръчник за внедряване за дежурния
```

#### `/plan-artifact`

Публикува плана като отделна страница, която може да се сподели: етапи, кое след кое върви, какво от кого е нужно. **[не за всички планове]** – публикуването изисква влизане в claude.ai. Удобно е, когато план, събран в режим на планиране, трябва да се покаже на хора, а не да се преразказва. От `/doc` се отличава само с шаблона: тук е план, а не произволен документ.

После уточнявате какво трябва да има в плана; резултатът е страница с етапите и връзка към нея.

#### `/artifact-pr-review [номер или връзка]`

Разглежда pull request и публикува разбора като отделна страница: заключение, препоръка, спорни места, слепи зони. **[не за всички планове]** – публикуването изисква влизане в claude.ai. Аргументът е номерът на PR или връзка към него. Нужна е, когато разборът трябва да се покаже на автора и на останалите; да не се бърка с `/code-review` – тя търси дефекти и работи в терминала, а тази прави четима страница със заключението.

Работата върви на два хода и не е мигновена: първо PR-ът се чете целия и чак след това се публикува страницата, връзката към която получавате.

```
/artifact-pr-review 1234
```

#### `/artifact-dashboard`

Сглобява дашборд по готов шаблон: показатели, графики, срезове на една страница. **[не за всички планове]** – публикуването изисква влизане в claude.ai. Взима се, когато има числа и те трябва да се покажат цялостно: статус на проекта, резултати от изпълнение, метрики за период. Шаблонът задава оформлението и вида – от вас са данните и разбирането кое тук е главното.

После давате данните и казвате кое в тях е главното; накрая остава връзка към сглобения дашборд.

```
/artifact-dashboard седмични метрики на опашката: дължина, време на изчакване, дял на повторенията
```

#### `/artifact-report`

Отчет по готов шаблон: изводите отгоре, разделите с подробности отдолу. **[не за всички планове]** – публикуването изисква влизане в claude.ai. Става за резултати от одит, разбор или голямо изпълнение, когато резултатът трябва да се предаде на хората цялостно, а не да се преразказва на парчета. Разликата от дашборда е, че тук има текст и разсъждение, а не плочки с числа.

После казвате за какво е отчетът; резултатът е публикувана страница и връзка към нея.

```
/artifact-report резултати от теста за натоварване за съседния екип
```

#### `/artifact-data-table`

Публикува данните като таблица по готов шаблон – като отделна страница вместо дълга простиня в терминала. **[не за всички планове]** – публикуването изисква влизане в claude.ai. Нужна е, когато редовете са повече, отколкото се събират в отговор, и искате да ги разгледате. Данните се взимат от това, което сте дали или което се е натрупало в тази сесия.

После давате редовете и колоните; накрая – връзка към страницата с таблицата.

```
/artifact-data-table таблица със SLA по услуги от последния отчет
```

#### `/artifact-explainer`

Страница с обяснение по готов шаблон: разбор на една тема или механизъм стъпка по стъпка. **[не за всички планове]** – публикуването изисква влизане в claude.ai. Взима се, когато трябва да обясните устройството на нещо на колега или на нов човек в екипа и обяснението трябва да живее по-дълго от един разговор. От отчета се отличава със задачата: отчетът съобщава резултат, а обяснението учи да се разбира.

После назовавате темата; резултатът е страница с разбор и връзка към нея.

```
/artifact-explainer как е устроена нашата схема за идемпотентност на поръчките
```

#### `/artifact-components`

Включва готови повторно използваеми компоненти, от които се сглобява артефактът. Смисълът е прост: да не се рисува всеки път отново това, което вече е направено и изглежда прилично. Сама нищо не публикува – работи върху страницата, която правите като следваща стъпка.

След извикването на екрана нищо не се появява: наборът от компоненти просто се оказва в контекста.

#### `/artifact-design`

Правила за оформление на артефактите: изграждане на страницата, типография, тъмна тема и, което е по-важно, съразмерност на усилията със задачата. Зареждат се, преди да правите страница, за да изглежда като готова вещ, а не като чернова от терминала. Нищо не публикува и не отпечатва.

#### `/artifact-diagramming`

Как се рисуват схеми, които показват реалния механизъм, а не набор от кутийки със стрелки: кога схемата изобщо е нужна, какво трябва да има на нея и как да се направи четима в светла и тъмна тема. Зарежда се, когато в артефакта е нужна схема. Нищо не публикува и на екрана не извежда.

#### `/artifact-capabilities`

Описва какво може публикуваната страница по време на изпълнение: да чете вашите данни, да запомня действията на посетителите (анкета, чеклист, документ, който се редактира направо на страницата), да държи общо състояние, да пита Claude. Зарежда се, преди да поискате такава страница: без това ще се получи обикновен статичен HTML, който нищо не помни. Наборът от възможности зависи от акаунта и командата показва какво е достъпно именно за вас.

#### `/dataviz`

Правила за оформление на графики и дашборди: какъв тип графика за какви данни, палитри, оси, надписи, достъпност, поведение в тъмна тема. Зареждат се, преди да е написан първият ред код на графика – да се преработва после излиза по-скъпо. Работи не само за артефакти: правилата са същите и за картинка, и за код с коя да е библиотека.

Самото извикване нищо не извежда: правилата се зареждат и действат върху следващата графика.

#### `/whiteboard`

Обща дъска: вие рисувате на ръка, а отговорите идват направо върху нея. **[не за всички планове]** – дъската живее като публикувана страница, а това значи, че е нужно влизане в claude.ai. Става там, където да обяснявате с думи е по-дълго, отколкото да хвърлите скица: разположение на елементи, структура на екран, връзки между части на системата.

Дъската се отваря като отделна страница и връзката към нея получавате в отговор на извикването.

```
/whiteboard скицирай обмена между услугата за поръчки и плащанията
```

#### `/whiteboard-mp`

Същото, но дъската е жива и върху нея рисува не само човекът: агентът добавя своето върху вашето и се получава съвместна работа. **[не за всички планове]** – като обикновената дъска, изисква влизане в claude.ai. Взима се, когато трябва не „да нарисуваш и да попиташ“, а да скицирате заедно.

Страницата е устроена по същия начин, с връзка в отговора; разликата е, че после на едно платно се оказват и вашите щрихи, и това, което е дорисувал агентът.

```
/whiteboard-mp да видим двамата къде в тази схема се губи идемпотентността
```

#### `/workshop`

Сглобява дизайн заедно с вас, по едно решение наведнъж: въпрос – ваш отговор – следваща стъпка, вместо голяма страница, направена веднага цялата. **[не за всички планове]** – резултатът се публикува, затова е нужно влизане в claude.ai. Става, когато и вие самите още не знаете какво искате и решението се избистря по пътя.

Разговорът започва с въпрос и върви с въпроси до края; готовата страница с връзка се появява чак накрая.

```
/workshop екран за настройки на известията – по едно решение наведнъж
```

#### `/design [sync|login|consent|revoke|import|export|status|описание]`

Хъбът на Claude Design – връзката на Claude Code с дизайн система в claude.ai. **[не за всички планове]** – има на Pro, Max, Team и Enterprise (на Enterprise е изключен по подразбиране), нужна е сесия, в която работят артефактите, и версия не по-ниска от 2.1.234; на Bedrock, Google Cloud, Foundry и Claude Platform on AWS командата я няма. Отделно не се таксува: разходът отива в същия общ лимит като при обикновената работа.

Официално това е една команда „с описание на дизайна“, а `/design-login` и `/design-sync` са две отделни. В бинарния файл `/design` допълнително разбира седем подкоманди и това никъде не е описано. Цялата тази история се появи във версия 2.1.234 и е отбелязана като изследователска – тоест ще се променя.

| Подкоманда | Какво прави |
|---|---|
| `status` | Показва състоянието на връзката с Claude Design |
| `login` | Влизане, то е и даване на достъп |
| `consent` | Никъде не е описана |
| `revoke` | Отнема дадения достъп |
| `import` | Взима оттам дизайн системата в проекта |
| `export` | Качва там дизайн системата на проекта |
| `sync` | Същото като отделната команда `/design-sync` |
| `описание` | Обикновено извикване: с думи казвате какъв дизайн е нужен |

Подкомандите отговарят по различен начин: `status` съобщава състоянието на връзката, `login` праща в браузъра за потвърждаване на достъпа, а `import` и `export` пренасят дизайн системата между проекта и claude.ai.

```
/design status                           # състояние на връзката с Claude Design
/design login                            # влизане
/design import                           # взимане на дизайн системата оттам
/design export                           # качване там
```

#### `/design-sync [подсказка]`

Сглобява дизайн системата на React проект направо от кода и я качва в claude.ai/design, за да изглежда всичко, което се рисува там, като вашия продукт, а не като чужд шаблон. **[не за всички планове]** – същите изисквания като при `/design`: влизане в claude.ai и достъпно публикуване на артефакти. Аргументът е кратка подсказка как да се нарече качването или на какво да се обърне внимание в проекта. Ако достъпът още не е даден, започва се с `/design-login`.

Всичко става на един ход и без въпроси: проектът се разглежда, дизайн системата се сглобява и заминава към claude.ai/design – там я и разглеждат.

```
/design-sync Acme DS
```

#### `/design-login`

Оторизира достъпа до дизайн системата – същия, който е нужен за качването. **[не за всички планове]** – работи там, където и останалият Claude Design, и изисква влизане в акаунт в claude.ai. Отделена е като самостоятелна команда, защото влизането се прави веднъж, а качванията после са много. Ако `/design-sync` се оплаква от достъпа, започва се оттук, а резултатът се проверява през `/design status`.

Влизането се потвърждава в браузъра; след това достъпът остава даден и не е нужно да се повтаря преди всяко качване.

### Конфигурация и интерфейс

#### `/config [ключ=стойност]`

Панел с настройки: без аргумент се отваря панел с всички настройки, които могат да се променят от интерфейса. Това е основната входна точка към цялото поведение на агента – от темата до модела и режимите на работа – и да надникнете тук е по-лесно, отколкото да помните имената на ключовете във файла с настройки. Псевдоним: `/settings`.

С аргумент настройката се задава веднага, без панел: `/config theme=dark`. Пълният списък с приеманите ключове отпечатва `/config --help` – не гадайте, той е по-къс от списъка с ключове на файла с настройки.

Директната форма се появи в 2.1.181, именуваните съкращения като `theme` и `model` – в 2.1.182. Работи и в неинтерактивен режим, и от телефона през отдалеченото управление, което я прави основния начин да смените настройка от скрипт.

Ограничението е точно едно, но неочевидно: **формата „ключ=стойност“ не може да включи настройка, която изисква вашето потвърждение в панела.** Например `autoContinueAtUsageLimit` тя може да изключи, но не и да включи – включването е придружено от диалог, а в тази форма няма къде да се покаже диалог.

```
/config                  # отваряне на панела с настройки
/config --help           # кои ключове приема формата ключ=стойност
/config theme=dark       # задаване веднага, без панел
/config model=sonnet     # същото за модела
```

#### `/permissions`

Правила за разрешаване и забраняване на инструменти, плюс раздел за авто-режима. Тук се идва в два случая: омръзнало ви е да потвърждавате една и съща безобидна команда – или, обратно, трябва да затворите на агента достъпа до нещо, което не бива да пипа. Правилото се записва в настройките и действа нататък само, без въпроси. Псевдоним: `/allowed-tools`.

Първо избирате списъка – разрешеното, забраненото или изискващото потвърждение, – а в него добавяте своето правило или махате излишното; промените действат от този момент, рестартиране не е нужно.

```
/permissions   # правила за правата на достъп
```

#### `/theme`

Смяна на цветовата тема на интерфейса. Темата променя само как Claude Code рисува себе си в терминала – подсветката на кода в диф-овете, рамките, селекциите; върху настройките на самия терминал не влияе.

Освен светла и тъмна има варианти за хора с цветна слепота, ANSI варианти за терминали със собствена палитра и **`auto`, която се нагажда към фона на терминала.** Собствените теми се слагат в `~/.claude/themes/` или идват от плъгини; направо в избора има опция за създаване на нова.

Изборът е със списък: избраната тема се прилага към целия интерфейс и се запомня в настройките, така че в следващата сесия ще остане същата.

```
/theme   # избор на тема
```

#### `/keybindings`

Отваря или създава файла с бързи клавиши – `~/.claude/keybindings.json`. В него се предефинират комбинациите на интерфейса, включително акорди от две последователни натискания. Нужна е, когато познатата комбинация се прихваща от самия терминал или от мултиплексор и до Claude Code просто не стига. Файлът се отваря в редактор; ако го е нямало, се създава.

```
/keybindings   # собствени бързи клавиши
```

#### `/terminal-setup`

Настройване на комбинациите на терминала – например Shift+Enter за пренасяне на ред. Промените отиват в конфигурацията на самия терминал, а не на Claude Code: достатъчно е да се изпълни веднъж на машината, но след преминаване към друг терминал ще се наложи да се повтори.

```
/terminal-setup   # Shift+Enter и други комбинации на терминала
```

#### `/statusline`

Настройване на реда за състояние: със собствен скрипт или генериран от вашия shell промпт. Редът за състояние е това, което Claude Code печата до полето за въвеждане: обикновено директория, клон и модел, но съдържанието е изцяло ваше. Скриптът се извиква при обновяване на реда и в него попада това, което е отпечатал.

Изборът тук е между два пътя: да се събере редът от поканата на вашата обвивка, за да изглежда като познатия промпт – или да посочите свой скрипт и сами да решавате какво ще има в него.

```
/statusline   # настройване на реда за състояние
```

#### `/voice [hold|tap|off]`

Гласово въвеждане. **[не за всички планове]** – диктуването изисква влизане в акаунт в claude.ai: с API ключ и при външни доставчици го няма. Върши работа, когато трябва да издиктувате дълго описание на задача, вместо да го пишете; режимът се избира според това как ви е удобно да държите ръцете си.

| Какво сте подали | Какво ще се случи |
|---|---|
| `hold` | Говорите със задържан бутон |
| `tap` | Натискате – говорите, натискате – изпращате |
| `off` | Изключване на гласовото въвеждане |

Аргументът се прилага веднага, без диалог: режимът на диктуване се превключва на посочения.

```
/voice hold   # говорене със задържан бутон
/voice tap    # натискане – говорене, натискане – изпращане
/voice off    # изключване на гласовото въвеждане
```

#### `/tui [default|fullscreen]`

Рендерер на интерфейса: `fullscreen` – на цял екран, без премигване, `default` – обратно към обикновения. Този на цял екран заема целия прозорец и сам се прерисува, затова дългият изход не подскача. Обикновеният пише в потока на терминала и историята се прелиства от самия терминал – ако копирате парчета изход с мишката или разчитате на скролването на терминала, останете на него.

Превключването не става във всяка сесия: ако в нея действат ограничения, които рестартът няма да пренесе – например права, зададени само за тази сесия, – командата ще откаже и нищо няма да промени.

```
/tui fullscreen   # рендерер на цял екран без премигване
/tui default      # обратно

# отказ в сесия с ограничения, които рестартът не пренася
# (така изглежда в документацията):
Cannot switch renderers in this session — it has restrictions a restart can't carry over (permission rules set for this session only). Nothing was changed. Running /tui fullscreen in a session started without them switches every later session too.
```

#### `/color [цвят|default]`

Цвят на реда за промпт за текущата сесия. Това не е тема, а именно цветът на реда за въвеждане; удобно е, когато са отворени четири терминала и не бива да се обърка кой е кой.

| Какво сте подали | Какво ще се случи |
|---|---|
| цвят от палитрата | Редът за промпт се оцветява в него до края на сесията |
| нищо | **Цветът се избира случайно** – това не е грешка, така е замислено |
| `default` | Връщане към обикновения цвят |

Палитрата е фиксирана: `red`, `blue`, `green`, `yellow`, `purple`, `orange`, `pink`, `cyan`, плюс `default` за нулиране. Ако е включено отдалечено управление, цветът се синхронизира и в уеб интерфейса.

```
/color purple    # цвят на реда за промпт
/color           # случаен цвят
/color default   # нулиране
```

#### `/scroll-speed`

Скорост на скролване с колелцето на мишката. Настройката е чисто битова: по подразбиране колелцето в дълга сесия или пълзи, или прескача нужното място, и тук това се оправя. Командата отваря избор на скорост, а резултатът може да се провери веднага, с колелцето.

```
/scroll-speed   # скорост на скролване с колелцето
```

#### `/focus`

Фокус-изглед: на екрана остават само вашият промпт, обобщението на инструментите и крайният отговор. Всичко междинно – подробностите от извикванията, съдържанието на прочетените файлове, дългият изход на команди – изчезва от екрана. Нужен е, когато сесията е нараснала и зад техническия изход се губи самият разговор, а също и когато показвате работата на агента на някой друг.

```
/focus   # да остане на екрана само същественото
```

#### `/hooks`

Преглед на настроените хукове по събития. Хукът е ваша команда, която Claude Code сам стартира при събитие: преди извикване на инструмент, след редакция на файл, в края на хода. Панелът показва какво към кое събитие е вързано – това е първото място, където да погледнете, когато хук мълчаливо не се задейства.

```
/hooks   # кои хукове са настроени
```

#### `/auto-mode-setup`

Запознаване на авто-режима с вашата среда и донастройване на правилата му. Авто-режимът е работа без потвърждение на всяка стъпка и по подразбиране той е предпазлив просто защото нищо не знае за вашия проект. Командата минава през средата заедно с вас и превръща отговорите в правила: какво тук може да се прави без питане и какво не бива да се пипа при никакви условия.

```
/auto-mode-setup   # запознаване на авто-режима със средата
```

#### `/sandbox [exclude "шаблон"|install]`

Настройване на пясъчника за команди. Пясъчникът ограничава къде стартираната команда може да пише и да ходи по мрежата и именно той позволява рутината да се изпълнява без потвърждаване на всяко извикване. Командата се вижда само там, където пясъчникът се поддържа.

| Какво сте подали | Какво ще се случи |
|---|---|
| нищо | Ще се отвори панелът на пясъчника със зависимости и предефиниции |
| `exclude "шаблон"` | Командата по шаблона се изважда от пясъчника |
| `install` | Доинсталиране на самия пясъчник (Windows) |

`exclude` е случаят, когато билд или команда за контейнер не работи вътре в изолацията и вие съзнателно я вадите оттам; списъкът се трупа в ключа `sandbox.excludedCommands`.

```
/sandbox                      # панел на пясъчника
/sandbox exclude "docker *"   # изваждане на команда от пясъчника
/sandbox install              # доинсталиране на пясъчника (Windows)
```

#### `/import [codex|gemini] [--dry-run] [--yes]`

Пренасяне на конфигурацията от друг агент за програмиране: файловете с инструкции, MCP сървърите, командите, субагентите и скиловете. **[не за всички планове]** – недостъпна е при външни доставчици и при изключено зареждане на сървърни флагове. Поддържат се `codex` и `gemini`.

| Аргумент | Какво прави |
|---|---|
| `codex` или `gemini` | Откъде да се пренася; без аргумент ще попитат |
| `--dry-run` | Показва какво би било пренесено, без нищо да променя |
| `--yes` | Пренася без интерактивен избор |

В неинтерактивен режим командата отпечатва какво е намерила и подсказва реда за потвърждаване на импорта. Изисква версия 2.1.213 и по-нова.

За файла `AGENTS.md`, който използват някои други агенти, `/import` не е нужен: от версия 2.1.277 Claude Code го чете сам, ако в проекта няма нито `CLAUDE.md`, нито `CLAUDE.local.md`. Ако `CLAUDE.md` има, добавете в него реда `@AGENTS.md` или пренесете конфигурацията с командата `/import` във вид, разбираем за Claude Code.

Без `--yes` изборът остава ваш: командата показва намереното по видове и пита какво точно да се пренесе – може да вземете само MCP сървърите, а командите и скиловете да оставите както са.

```
/import codex              # вземане на конфигурацията на друг агент
/import gemini --dry-run   # да видим какво би се пренесло
/import codex --yes        # пренасяне без въпроси
```

#### `/cloud-plugins`

Дали в облачните сесии да се използват плъгините, включени на тази машина. **[не за всички планове]** – самите облачни сесии изискват влизане през акаунт в claude.ai и са недостъпни с API ключ и при външни доставчици. Облачната сесия се стартира на чужда машина, където вашият набор от плъгини го няма: настройката решава дали да се пренася натам, или да се минава с това, което е вградено в Claude Code.

Изборът е прост, но с последствия: с плъгини облачната сесия се държи като вашата локална, без тях – работи на гола конфигурация, но пък не мъкнете в облака излишни източници.

```
/cloud-plugins   # плъгини в облачните сесии
```

#### `/skills`

Списък със скиловете и управление на тяхната видимост.

Описанията на всички достъпни скилове висят в контекста постоянно, всяка сесия, независимо дали ги използвате, или не. При голям набор от плъгини това е осезаем дял от прозореца – екранът `/skills` е за това.

Пишете – списъкът се филтрира по име, описание и източник. Клавишът `t` сортира по брой токени и тук обикновено се оказва, че половината от прозореца е заета от три скила, които не сте използвали нито веднъж. `Space` или `Enter` превключва видимостта на скила за модела и за менюто, `Esc` запазва и затваря.

Превключва се не всичко: скиловете от плъгини, скиловете с `disable-model-invocation: true` във frontmatter и тези, за които видимостта е зададена в корпоративните настройки или през `--settings`, не се поддават. Постоянният еквивалент е ключът `skillOverrides`, а да намерите това, което просто не се използва, помага `/skill-doctor`.

```
/skills   # списък със скиловете и тяхната видимост
```

#### `/plugin`

Управление на плъгините и маркетплейсите. Маркетплейсът е източник, от който се инсталират плъгини; самият плъгин носи със себе си команди, скилове, субагенти, хукове и MCP сървъри наведнъж, затова един плъгин може осезаемо да промени поведението на сесията. През този панел маркетплейсът се свързва, а плъгинът се инсталира, изключва и изтрива. Псевдоними: `/plugins`, `/marketplace`.

Редът на избиране е такъв: първо маркетплейсът, после плъгинът в него. Част от промените не влизат в сила мигновено – довършва ги `/reload-plugins`.

```
/plugin   # плъгини и маркетплейси
```

#### `/reload-skills`

Подхващане на скиловете и командите, променени на диска, без рестартиране на сесията. Нужна е, когато пишете свой скил и не искате да рестартирате при всяка промяна. Препрочитат се само файловете – разговорът и неговият контекст остават на място.

```
/reload-skills   # подхващане на промените в скиловете от диска
```

#### `/reload-plugins [--force]`

Активиране на отложените промени в плъгините – същото като `/reload-skills`, само че за плъгини. Върши работа веднага след `/plugin`, когато плъгинът вече е инсталиран, но сесията още не го вижда.

Смисълът на `--force` тук е обратен на интуитивния: това **не** е „препрочети по-дълбоко“. Ако презареждането би променило набора от заредени MCP инструменти, то ще нулира кеша на промпта и командата, след като предупреди, **ще откаже да го направи** – а `--force` я принуждава да го направи въпреки това. Тоест флагът преодолява отказа, а не задълбочава работата.

```
/reload-plugins           # прилагане на отложените промени в плъгините
/reload-plugins --force   # същото, дори ако това ще нулира кеша на промпта
```

### MCP и интеграции

#### `/mcp [reconnect|enable|disable [<сървър>|all]]`

Управление на MCP сървърите и тяхната OAuth оторизация. MCP сървърът е външен процес или услуга, която внася в сесията свои инструменти, промптове и ресурси: тракер на задачи, база, браузър, вътрешно API. Тук се идва, когато сървър е паднал по средата на работата, когато иска да влезете отново или когато инструментите му в момента само пречат – излишният сървър е по-добре да се изключи, отколкото да се държат описанията му в контекста. Самите сървъри се описват в конфигурацията, тук е само текущото им състояние.

| Какво сте подали | Какво ще се случи |
|---|---|
| нищо | Списък със сървърите и състоянието им |
| `reconnect <сървър>` | Вдигане на паднал сървър |
| `reconnect all` | Повторно свързване на всички |
| `disable <сървър>` | Временно изключване на сървър |
| `enable <сървър>` | Включване обратно |

В списъка срещу всеки сървър се вижда дали е свързан, дали е паднал или чака оторизация – по това се решава какво да се свърже наново и какво да се изключи до края на работата. При свързан сървър панелът показва и броя на инструментите му и отделно отбелязва този, който се е свързал, но не е дал нито един.

**Сървърите дават своите промптове като команди.** Те се появяват в менюто във вида `/име-на-сървъра:име-на-промпта` – и това е формата, която си струва да запомните, защото втората, `/mcp__сървър__промпт`, също работи, но се среща само в стари статии. Аргументите се подават през интервал и се режат по интервалите: всеки аргумент е един токен, фраза в кавички да се подаде като един аргумент няма да стане.

**Ресурсите на сървъра се вмъкват с `@`.** Формата е `@сървър:протокол://път` и това е механизъм, отделен от инструментите: не „извикай инструмент“, а „сложи съдържанието в контекста“.

Във фонова сесия, към която не е свързан терминал, панелът изобщо няма да се отвори: сесията ще премине в състояние „нужно е въвеждане“, а за управление на сървърите ще предложат формата `/mcp enable|disable|reconnect <сървър>`.

```
/mcp                                     # списък със сървърите и състоянието им
/mcp reconnect github                    # вдигане на паднал сървър
/mcp disable jira                        # временно изключване на сървър
/jira:create_issue login-bug high        # промпт на сървъра, сегашната форма
```

#### `/ide [open]`

Интеграции с IDE и техният статус. Заради тази връзка промените се виждат в редактора като диф-ове, а фрагментът, избран там, попада в контекста, затова първото, към което посягате при „в редактора нищо не се случва“, е тук: обикновено се оказва, че връзката не се е установила. Без аргумент показва статуса на интеграцията с редактора, с `open` – отваря файл в свързаната IDE.

```
/ide                                     # статус на интеграцията с редактора
/ide open                                # отваряне на файл в свързаната IDE
```

#### `/chrome`

Настройки на Claude in Chrome. **[не за всички планове]** Разширението работи само при влизане в акаунт в claude.ai – с API ключ и при външни доставчици го няма. Claude in Chrome е когато агентът ходи по страниците на вашия собствен браузър: кликва, чете страницата, гледа конзолата. Разрешенията се дават по сайтове и без тях нищо няма да се изпълни, затова тук се наднича преди първата задача в браузъра.

```
/chrome                                  # настройки за работа в браузъра
```

### Акаунт и оторизация

#### `/login`

Влизане в акаунт на Anthropic или превключване на акаунта. Тук се избира и с какво се плаща работата – с абонамент за claude.ai или с API ключ от Console, а от това зависи не само сметката: част от възможностите (уеб сесиите, мобилното приложение, кредитите извън плана) има само при абонамент. Влизането става в браузъра, след потвърждаване управлението се връща в терминала.

Към тази команда насочват и съобщенията, че трябва да влезете наново: `Not logged in · Please run /login`, `OAuth token revoked · Please run /login`, `OAuth token has expired · Please run /login` – и трите са дадени в документацията дословно.

```
/login                                   # влизане или превключване на акаунта
```

#### `/logout`

Излизане от акаунта. Запазените данни за достъп се изтриват и после сесията не може да работи, докато не влезете отново – нужно е, когато машината е споделена или когато трябва начисто да превключите към друг акаунт.

```
/logout                                  # излизане
```

#### `/setup-bedrock`

Настройване на Amazon Bedrock: оторизация, регион, фиксиране (pin) на модели. Нужна е там, където работата не върви директно през Anthropic, а през AWS – обикновено заради изискване трафикът да се държи в собствения облак. Вижда се при включен Bedrock.

Заедно със `/setup-vertex` това е пример за команди, скрити според състоянието: появяват се само когато е зададена съответната променлива на средата на доставчика. Докато я няма, няма ги и в `/help`.

```
/setup-bedrock                           # настройване на Amazon Bedrock
```

#### `/setup-vertex`

Настройване на Google Cloud: оторизация, проект, регион, фиксиране (pin) на модели. Смисълът е същият като при Bedrock: трафикът върви през вашия облак и се плаща там. Както `/setup-bedrock`, вижда се само при зададена променлива на средата на доставчика.

```
/setup-vertex                            # настройване на Google Cloud
```

#### `/install-github-app`

Инсталиране на Claude GitHub Actions за хранилището. Това е приложението, чрез което прегледът на pull request-и се случва от страна на GitHub, а не във вашия терминал. Инсталира се веднъж за хранилище; локалната `/code-review` не зависи от него и работи без каквато и да е инсталация.

```
/install-github-app                      # поставяне на ревю в CI за хранилището
```

#### `/install-slack-app`

Инсталиране на Slack приложение. **[не за всички планове]** Claude Code в Slack изисква влизане в claude.ai – с API ключ и при външни доставчици е недостъпен. След инсталацията задачата може да се постави направо от разговора и отговорът ще дойде там – удобно е там, където обсъждането и без това върви в Slack. В корпоративно пространство инсталацията може да опре в правата на администратора.

```
/install-slack-app                       # поставяне на приложението в Slack
```

#### `/privacy-settings`

Преглед и промяна на настройките за поверителност: какво излиза навън от вашата работа и как е разрешено да се използва. Тук се идва преди работа със затворен или чужд код – за да видите текущото състояние, а не да гадаете за него. В корпоративните акаунти част от превключвателите са затворени от политиката на организацията.

```
/privacy-settings                        # какво излиза навън
```

### Използване и разходи

#### `/usage`

Разход на сесията, използване на лимитите на плана и статистика за активността. Псевдоними: `/cost`, `/stats`. Тук се идва в два случая: когато трябва да разберете дали ще доживеете до нулирането на лимита и когато разходът изведнъж е скочил и трябва да видите кой го създава.

Екранът показва три неща: колко е похарчено в тази сесия, доколко са запълнени лимитите на плана и за какво отиват токените – с разбивка по скилове, субагенти, плъгини и отделни MCP сървъри, плюс бележки за поведение, което дава повече от десет процента от разхода. Клавишите `d` и `w` превключват прозореца между денонощие и седмица, а планираните задачи от 2.1.242 получават свои редове.

Следват четири неща, които е важно да се разбират, и нито едно не е очевидно.

**Разбивката се изчислява по локалната история на сесиите.** Тоест по транскриптите на тази машина. Работата от друг компютър и от уеб интерфейса не попада в нея – при това самите лимити са общи за акаунта. Разминаването между „почти нищо не съм похарчил“ и „лимитът е на изчерпване“ обикновено се обяснява точно с това.

**Лимитите са няколко и смяната на модела помага само при един от тях.** Съобщенията „изчерпахте лимита на сесията“ и „изчерпахте седмичния лимит“ се отнасят до прозорци, общи за всички модели – `/model` тук няма да помогне. И само след „изчерпахте лимита на Opus“ или „лимита на Sonnet“ преминаването към модел от друго семейство ще ви върне в работата. От версия 2.1.234 Claude Code умее да изчака нулирането и да продължи прекъснатата задача сам; включва се през `/rate-limit-options` и ключа `autoContinueAtUsageLimit`.

**Кешът на промпта живее час само при абонамент.** Щом започнете да харчите кредити извън плана, времето на живот на кеша пада от час на пет минути – и същата пауза за обяд, която вчера не е струвала нищо, днес се превръща в преработване на целия контекст наново. При API ключ и при облачните доставчици по подразбиране са пет минути.

**Броячът на сесията се нулира при `/clear`.** До версия 2.1.211 той се трупаше през изчиствания и числата от старите статии не се връзват със сегашните.

Ако сървърът за лимитите е недостъпен, екранът ще покаже последните заредени данни с бележка и ще предложи да опитате пак с клавиша `r`. Докато са свързани кредити извън плана, за тях тук има отделен ред.

Незабележимите пера в разходите, които не се виждат в разбивката, но реално горят лимита, докато вие не правите нищо: планираните задачи се събуждат и тръгват с целия контекст; съобщение от друга ваша сесия идва като нов ход (лекува се с `crossSessionInbound: "hold"`); проверките на активната цел започват ходове, докато върви фонова работа; всеки жив тиймейт харчи, докато не приключи. И `/compact` сам по себе си е голяма заявка, докато `/clear` не струва нищо.

```
/usage                                   # лимити, разход, разбивка
# изходът изцяло, както го е цитирал авторът на доклада за грешка
Session
Total cost:            $86.94
Total duration (API):  1h 31m 17s
Total duration (wall): 1d 22h 35m
Total code changes:    2538 lines added, 312 lines removed
Usage by model:
    claude-opus-4-8:   9.0k input, 461 output, 50.4k cache read, 29.9k cache write ($0.3802)
    claude-haiku-4-5:  2.0k input, 43 output, 0 cache read, 0 cache write ($0.0022)
    claude-sonnet-5:   86.5k input, 448.0k output, 197.4m cache read, 3.4m cache write ($86.55)

Current session: 17% used, resets 1:29pm (Europe/Madrid)
Current week (all models): 19% used, resets Aug 13 at 8:59am (Europe/Madrid)
# на отделен ред там, от 2.1.251 насам – за кеша на промпта; така изглежда в документацията
Prompt cache (main):   14 requests · 91% of input tokens from cache · 2 misses (last 6m 10s ago, 310.2k tokens re-cached) · 1 expected rebuild (compaction or tool-result clearing) · warm (1h TTL, last activity 40s ago)

/stats                                   # същото, веднага в раздела за статистика
/cost                                    # същото, в обикновен вид
```

#### `/usage-credits`

Настройване на кредити, за да продължите работата при достигане на лимита на плана. **[не за всички планове]** Командата работи само след влизане с абонамент за claude.ai през `/login`; при оторизация с API ключ я няма. Кредитите са платен извън абонамента разход по обикновените тарифи на API, сметката за тях е отделна от плана. Без тях при изчерпан лимит просто чакате нулирането на прозореца; с тях ще дойде предложение да продължите и по-нататъшната работа ще върви срещу пари.

Накъде точно води командата, зависи от вашата роля: абонат на Pro или Max – към страницата за разходите в claude.ai, участник в Team или Enterprise с достъп до таксуването – към админските настройки, а участник без такъв достъп тя ще помоли да потвърди и ще изпрати заявка до администраторите на организацията. На самата страница се избират три неща: дали да се включат кредитите, или не, да се зададе месечен таван на разходите или да се махне, и да се зареди балансът. При абонирали се през мобилното приложение включването и зареждането работят само в уеб версията.

Помнете страничния ефект, описан по-горе: с началото на разходите извън плана кешът на промпта живее пет минути вместо час.

```
/usage-credits                           # свързване на кредити извън плана
```

### Отдалечена работа и среди

#### `/desktop`

Продължаване на текущата сесия в десктоп приложението. **[не за всички планове]** На приложението му трябва влизане в claude.ai – при API ключ и при външни доставчици го няма. Сесията се премества заедно с контекста и историята: задачата не е нужно да се поставя наново. Върши работа, когато е по-удобно да продължите работата в прозореца на приложението, а не в терминала. Псевдоним: `/app`.

```
/desktop                                 # продължаване в приложението
```

#### `/teleport`

Издърпване на уеб сесия в този терминал. **[не за всички планове]** Уеб сесиите са research preview за Pro, Max и Team (при Enterprise е нужен подходящ тип място), изискват влизане в claude.ai и са недостъпни на Bedrock, Google Cloud и Microsoft Foundry. Контекстът, историята и състоянието на работата се пренасят при вас и нататък работите локално – това е нужно, когато задачата е поставена от телефона или от браузъра, а да се довърши е по-удобно на ръка. Избира се от активните ви уеб сесии; след избора терминалът продължава тази, която сте посочили. Отделна такса за облачната машина няма, харчат се обикновените лимити на акаунта. Псевдоним: `/tp`.

```
/teleport                                # взимане на уеб сесия в терминала
```

#### `/remote-control`

Отваряне на сесия за управление от телефон или от уеб. **[не за всички планове]** Изисква влизане в claude.ai; с API ключ е недостъпно. Работата при това остава на вашата машина – отвън само изпращате заявки и четете отговори, затова достъпът до хранилището и средата не заминава никъде. Удобно е, когато върви нещо дълго и искате да го следите, без да седите на бюрото. Псевдоним: `/rc`.

Отказът изглежда разбираемо: ако сесията работи не през api.anthropic.com, командата направо назовава причината и казва коя променлива на средата да се махне.

```
/remote-control                          # отваряне на сесия за телефона
# отказ при зададена CLAUDE_CODE_USE_BEDROCK – така изглежда в документацията
Remote Control is only available when using Claude via api.anthropic.com. CLAUDE_CODE_USE_BEDROCK is set, so this session is using Amazon Bedrock — unset it (or run in a shell without it) to use Remote Control.
```

#### `/session`

Показване на адреса на отдалечената сесия и QR код за нея. Нужна е след `/remote-control`, когато сте загубили връзката или свързвате второ устройство: с телефон е по-лесно да насочите камерата, отколкото да пренасяте адреса на ръка. Работи там, където и отдалеченото управление – тоест при влизане в claude.ai. Псевдоним: `/remote`.

```
/session                                 # адрес на сесията и QR код
```

#### `/remote-env`

Среда по подразбиране за уеб сесиите и телепорта. Смисълът е облачната машина да стартира вече подготвена за вашия проект, а не празна: иначе още първият билд или изпълнение на тестове се спъва. Настройва се веднъж и после се прилага към всички нови уеб сесии. Отнася се само до уеб, на който му трябва влизане в claude.ai.

```
/remote-env                              # среда по подразбиране за уеб
```

#### `/web-setup`

Свързване на GitHub към Claude Code в уеб през локалния `gh`. Тоест да се даде навън достъпът, който на вашата машина вече е настроен, вместо отделна оторизация в браузъра. Прави се веднъж; без това уеб сесията няма да види частните хранилища. Както цялото уеб направление, изисква влизане в claude.ai.

```
/web-setup                               # свързване на GitHub към уеб
# така изглежда в документацията
Connected as <your-github-username>
```

### Диагностика и помощ

#### `/help`

Справка и списък с достъпните команди. Списъкът се сглобява за вашата сесия: командите, скрити според състоянието (като настройването на облачни доставчици) или изключени от администратора, няма да се появят в него – затова това е честният отговор на въпроса „какво изобщо имам“, за разлика от документацията. Добра проверка след инсталиране на плъгин: командите му трябва да се появят тук.

```
/help                                    # какво изобщо е достъпно
```

#### `/status`

Версия, модел, акаунт, връзка с API и статуси на инструментите. Първото място, където се гледа, когато поведението не се връзва с очакванията: не е този модел, не е този акаунт, не е стигнала настройка. Работи дори докато върви отговор.

Отваря панела с настройки в раздела за състоянието. Освен версията, модела, акаунта и връзката там има ред за вида на сесията: `interactive` за обикновената, `background job · attached` или `background job · unattended` за фонова – според това дали към нея е свързан терминал. Редът се появи в 2.1.221.

Плюс това от 2.1.243 там има и ред за пропуснатите източници на корпоративни настройки: ако админът е сложил файл с политика, а действа друг, с по-висок приоритет, тук ще се види кой точно е игнориран. Това е първото, което трябва да се гледа, когато „настройката от админа не е стигнала“.

Според документацията в същия раздел се срещат редове за профила, начина на влизане, API ключа, адреса на хоста и прокси, а зад корпоративен шлюз – редове за доставчика с неговия базов адрес.

```
/status                                  # версия, модел, акаунт, връзка
# редове от раздела за състояние, както ги е цитирал авторът на доклад за грешка (билд 2.1.199)
Version: 2.1.199
Session ID: 352ea81c-819d-4028-bba5-daef515d0815
Login method: Claude Enterprise account
…
Model: claude-fable-5[1m] (claude-fable-5)
Setting sources: User settings, Enterprise managed settings (remote)
```

#### `/doctor`

Диагностика на инсталацията и привеждане на конфигурацията в ред. Псевдоним: `/checkup`. Тук се идва, когато `CLAUDE.md` е нараснал и всяка заявка мъкне килобайти инструкции или когато след обновяване нещо се държи странно.

От версия 2.1.205 това не е екран с отчет, а пълноценен скил, който **променя вашата конфигурация**. Какво прави: чисти дублиранията между локалния и комитнатия `CLAUDE.md`; подрязва комитнатия, като изхвърля това, което агентът и без това ще изведе от кода; пренася вечно зарежданите инструкции в скилове и вложени файлове, зареждани при нужда; предлага авто-режимът да стане режим по подразбиране и предварително да се одобрят безопасните команди, които най-често сте забранявали. Първо показва находките, после променя.

Проверката обхваща и това, което е наблизо: здравето на инсталацията, счупените файлове с настройки, неизползваните разширения и едноименните субагенти в една папка – за всяка находка се предлага поправка.

Терминалният `claude doctor` е все така диагностика без поправки и без стартиране на сесия; чете файловете с настройки в текущата папка, без да пита за доверие към нея.

Командата остава достъпна, дори когато вградените скилове са изключени изцяло: тя е нарочно отбелязана като оцеляваща при `disableBundledSkills`. Да се скрие може с променливата `DISABLE_DOCTOR_COMMAND` или със запис `"doctor": "off"` в `skillOverrides`.

```
/doctor                                  # проверка и поправяне на конфигурацията
```

#### `/feedback [доклад]`

Изпращане на отзив за Claude Code. Текстът може да се подаде направо в аргумента или да се напише в отвореното поле. Става за „работи не така, както очаквах“ и за пожелания; за конкретна повреда с приложен разговор има `/bug`.

```
/feedback                                # изпращане на отзив
/feedback промените се прилагат, но не се показват в диф-а
```

#### `/bug [доклад]`

Съобщаване за грешка или споделяне на разговор. Използва се и когато просто трябва да предадете на някого хода на сесията изцяло. Преди да приложите разговора, трябва да си спомните какво има в него: имената на вътрешни услуги, парчета частен код и всичко, което е попаднало в контекста, ще заминат заедно с него. Псевдоним: `/share`.

Преди изпращане командата пита дали да приложи разговора.

```
/bug                                     # съобщаване за грешка
```

#### `/heapdump`

Снемане на дъмп на паметта – за диагностика на високото ѝ потребление. Скрита.

Записва снимка на паметта и разбор на потреблението на работния плот (в домашната папка на Linux без работен плот). Командата е скрита не със сървърен флаг, а с това, че не се показва в менюто: набира се цялата и работи. Важно предупреждение: при обръщане към поддръжката прилагайте **само** файла с разбора, а самата снимка съдържа целия ви разговор и данните за достъп и да се споделя не бива.

```
/heapdump                                # дъмп на паметта на работния плот
```

#### `/insights`

Отчет с анализ на вашите сесии: зоните на проекта, шаблоните на работа, точките на триене. Това е поглед към навиците, а не към парите – колко е похарчено, показва `/usage`. Има смисъл да се гледа веднъж на няколко седмици: от отчета обикновено излиза това, което отдавна е време да се изнесе в `CLAUDE.md` или в скил.

За едно изпълнение се разглеждат до двеста още невиждани сесии, съвсем късите се прескачат. Ако нещо е останало зад борда, в шапката на отчета до разгледаното число стои общото – например `200 sessions (412 total)`.

```
/insights                                # анализ на моите сесии
```

#### `/skill-doctor`

Кои заредени скилове не се използват и напразно заемат контекст. Всеки включен скил струва място в прозореца: описанието му се зарежда винаги, а тялото – само при задействане, и десетина забравени скила осезаемо стесняват полезния контекст. По резултатите се решава кое да се изключи и кое да се пренапише така, че да се задейства по предназначение.

```
/skill-doctor                            # кои скилове напразно висят в контекста
```

#### `/explain-usage`

Накъде са отишли токените на тази сесия, на човешки език. **[Скил]** За разлика от `/usage`, където има числа и разбивка, тук се получава разбор с изводи: кои ходове са излезли скъпи и защо. Полезно е, когато лимитът се топи по-бързо от очакваното, а по таблицата не е ясно какво точно да се прави.

```
/explain-usage                           # накъде са отишли токените
```

#### `/install [версия] [--force]`

Инсталиране на нативния билд направо от сесията – без пакетен мениджър и без излизане в терминала. Върши работа, за да преминете от npm инсталация към нативна или да се върнете към конкретна версия, когато свежата е счупила нещо важно. Аргументът е версия: `stable` или конкретен номер; `--force` я инсталира върху текущата.

```
/install stable                          # инсталиране на стабилния билд
/install 2.1.236 --force                 # конкретна версия, върху текущата
```

### Информация и документация

#### `/release-notes`

Списък с промените по версии: какво се е появило, какво са поправили, какво са изключили. Да се чете си струва след всяко обновяване – значителна част от поведението на Claude Code се променя от билд на билд и „вчера работеше“ най-често се обяснява точно тук.

Приятна подробност: бележките се печатат в транскрипта, **но не попадат в контекста на модела**. Някога не е било така и показването на всички промени подмесваше целия чейнджлог във всяка следваща заявка.

```
/release-notes                           # какво се е променило по версии
```

#### `/powerup`

Кратки интерактивни уроци за възможностите. Смисълът е, че много неща тук сами не се намират: планове, скилове, фонови задачи, хукове. Урокът върви направо в сесията и отнема няколко минути – това е начин да научите за едно нещо, а не да четете цялата документация.

```
/powerup                                 # кратък урок за възможностите
```

#### `/mobile`

QR код за инсталиране на мобилното приложение. Приложението е нужно заради работа извън работното място: да поставите задача по пътя и да видите с какво е свършила. Псевдоними: `/ios`, `/android`.

```
/mobile                                  # QR код на мобилното приложение
```

#### `/radio`

Lo-fi радио Claude FM в браузъра. Точно това, което изглежда: фонова музика, няма отношение към работата на агента.

```
/radio                                   # фонова музика
```

#### `/passes`

Споделяне на безплатна седмица с приятели и получаване на кредити. Командата не се вижда на всички: появява се само при акаунти, за които е достъпна, – така че в чужд `/help` може да я няма.

```
/passes                                  # споделяне на безплатна седмица
```

#### `/upgrade`

Преминаване към Max: по-високи лимити, повече Opus. Обикновено тук се попада направо от съобщението за изчерпан лимит. Ако опирате не в плана, а в конкретен модел, първо е по-евтино да опитате `/model` – смяната на семейството на модела решава точно този случай.

```
/upgrade                                 # преминаване към Max
```

#### `/stickers`

Поръчване на стикери. Няма отношение към работата на агента: отваря се форма за поръчка.

```
/stickers                                # поръчване на стикери
```

#### `/team-onboarding`

Генериране на онбординг ръководство за екипа от вашата история на използване. Смисълът е да не пишете такъв документ от нулата: той се сглобява от това как работите на практика, а не от общи съвети. На изхода е текст, който се редактира на ръка и се слага в хранилището.

```
/team-onboarding                         # ръководство за екипа от моята история
```

### Премахнати и изключени команди

Свои раздели нямат – да ги набирате няма смисъл. Таблицата е нужна затова, че половината статии в интернет все още ги препоръчват и когато командата „не работи“, най-лесно е да погледнете тук.

**Премахнати напълно:**

| Команда | Какво се е случило с нея |
|---|---|
| `/vim` | Премахната в 2.1.92. Режимът на клавишите се превключва в `/config` с полето „Editor mode“ или с ключа `editorMode`. |
| `/pr-comments` | Премахната в 2.1.91. Просто помолете агента да покаже коментарите към pull request. |
| `/output-style` | Обявена за остаряла в 2.1.73 и премахната в 2.1.91. Стилът на отговорите се задава с ключа `outputStyle`. |
| `/ultraplan` | Премахната. Вместо нея – режимът на планиране, `/plan`. |
| `/agents` | Формално е останала, но само отговаря, че субагентите се създават с файлове в `.claude/agents/`. Фоновите агенти са `claude agents` в терминала. |
| `/extra-usage` | Преименувана на `/usage-credits` в 2.1.144. |
| `/init-verifiers` | Никога не е съществувала – ако сте я срещнали в чужда статия, това е измислица. |
| `--enable-auto-mode` | Флагът е премахнат в 2.1.111. Вместо него – `--permission-mode auto`. |

**Изключени отвътре в билда 2.1.251:** регистрирани са, но не работят и в менюто не се показват.

| Команда | Какво да се използва вместо нея |
|---|---|
| `/version` | Версията на сесията показва `/status`, версията на бинарния файл – `claude --version`. |
| `/update` (псевдоним `/restart`) | Обновяването – `claude update` в терминала. |
| `/loops` | Какво и с каква периодичност върви, показва `/usage`; самите цикли се създават с `/loop`. |
| `/wellbeing` (псевдоними `/breaks`, `/break-reminder`, `/downtime`) | Самите настройки работят: обектите `breakReminder` и `quietHours` във файла с настройки. |
| `/pause-memory` (псевдоними `/memory-pause`, `/toggle-memory`) | Автопаметта се изключва с ключа `autoMemoryEnabled`. |

Има и още команди, които се появяват **според състоянието** и които няма да видите, докато състоянието не настъпи: `/limit-reset` и `/low-priority` – когато сте опрели в лимита на сесията, `/rate-limit-options`, `/pro-trial-expired`, `/design-consent` и `/design-revoke`, а `/setup-cowork` живее само в режим Cowork. Плюс два съвсем вътрешни входа, `__remote-workflow` и `workflow-launch-exec`, през които сървърът предава на сесията готов воркфлоу.

И отделна категория – **скиловете само за модела**: `keybindings-help`, `memory-types`, `cowork-plugin`. Агентът ги зарежда сам, да се наберат не могат. Механизмът е общ и е достъпен и за вас – това е полето `user-invocable: false` във frontmatter на скила.

Две жилави заблуди накрая. **Командата `/alias` не съществува**: под това име в бинарния файл се намира описание на системната утилита `alias` за автодопълване на команди, въвеждани през `!`. И **файлът `.claudeignore` също не съществува** – за да накарате агента да игнорира файлове, използвайте `.gitignore`, който се отчита по подразбиране, или `.ignore`.

### Как менюто търси команда

Дреболия, която спестява нерви. От версия 2.1.236 подсветката в менюто се задейства, ако буквите след `/` съвпадат с името на командата или с нейния псевдоним – от началото на името **или от началото на дума в него**, като разделителите `:`, `_` и `-` при сравнението се игнорират. Затова `/adddir` подсветява `/add-dir`, а `/new` подсветява `/clear` през псевдонима ѝ.

Какво се е променило тогава и е по-важно: **правописна грешка вече не се налучква.** Преди Enter върху несъществуваща команда стартираше подобна. Сега след правописна грешка нищо не е подсветено, близките варианти остават в списъка и се избират със стрелките или с Tab, но Enter ще изпрати вашия текст както си е и ще съобщи за непозната команда.

Недостъпните команди от менюто просто изчезват – ще видите „няма команди по такава заявка“. Някои вместо това отговарят със свое съобщение за недостъпност: например `/schedule` при API ключ ще каже, че изисква акаунт. И с частично име скрита команда не може да се извади – трябва да се набере цялата.

### Собствени команди

Собствената слеш команда е файл `SKILL.md` в папката на скила. Преди за това имаше отделна същност в `.claude/commands/`; сега командите и скиловете са слети в едно, старите файлове продължават да работят и дават точно същата команда.

Къде да търсите и къде да поставяте:

| Местоположение | Обхват | Име на командата |
|---|---|---|
| `~/.claude/skills/<име>/SKILL.md` | личен, във всички проекти | `/<име на папката>` |
| `<проект>/.claude/skills/<име>/SKILL.md` | проектен, комитва се | `/<име на папката>` |
| `.claude/commands/<име>.md` | стара форма, работи | `/<име на файла>` |
| плъгин | откъдето е инсталиран | `/<плъгин>:<име>` |

**Името на командата се взема от името на папката, а не от полето `name`.** При личните и проектните скилове `name` е само етикет в списъка. При плъгинните е обратното: `name` заменя последния сегмент, и `my-plugin/skills/review/` с `name: fancy` дава `/my-plugin:fancy`. Краткият вариант `/fancy` също ще сработи, ако името не е заето от нищо друго.

Най-простият пример:

```markdown title=".claude/skills/fix-issue/SKILL.md"
---
name: fix-issue
description: Разгледай issue по номер, намери причината и предложи поправка
argument-hint: <номер на issue>
allowed-tools: Bash(gh issue view:*), Bash(gh pr create:*)
---

Вземи issue номер $0 от това хранилище.

Текущо състояние на клона:

!`git status --short`

Прочети описанието, намери причината в кода, предложи минимална поправка
и обясни защо е минимална.
```

Извиква се като `/fix-issue 4821`. Тук `$0` е първият аргумент, тоест `4821`, а редът с `!` се изпълнява, преди текстът да стигне до модела, и се заменя със собствения си изход. И за двете – подробно по-долу.

#### Полета на frontmatter

Те са двайсет. Полезно е да знаете, че изобщо съществуват – половината от тях решават проблеми, които иначе се решават с патерици.

| Поле | Какво задава |
|---|---|
| `name` | Име; при личните и проектните скилове – само етикет |
| `description` | Описание, по което моделът решава дали скилът е подходящ |
| `when_to_use` | Уточнение кога да се вземе |
| `argument-hint` | Подсказка за аргументите в менюто |
| `arguments` | Списък с именувани аргументи, които позиционно се съпоставят с `$име` |
| `disable-model-invocation` | Забранява на модела да извиква скила сам |
| `user-invocable` | `false` – скилът е само за модела, не може да се въведе |
| `allowed-tools` | Какво да се разреши предварително за този ход |
| `disallowed-tools` | Какво да се забрани |
| `model` | Модел за остатъка от хода; приема `inherit` |
| `effort` | Ниво на усилие: от `low` до `max` |
| `context` | `fork` – изпълнява скила в субагент |
| `agent` | Кой тип агент да се вземе при `context: fork` |
| `background` | `false` – изчаква резултата от форкнатия скил |
| `hooks` | Хукове, които живеят заедно със скила |
| `paths` | Ограничава автоматичното активиране до тези пътища |
| `shell` | С какво да се изпълняват вградените команди: `bash` или `powershell` |
| `metadata` | Произволни данни |
| `license` | Лиценз |
| `compatibility` | Изисквания за съвместимост |

Три ограничения, на които се спъват. Frontmatter се чете, **само ако отварящите `---` са на първия ред на файла**. Полетата `description` и `when_to_use` в листинга се орязват до хиляда и петстотин знака – всичко над това моделът няма да види при избора на скил. А в старите файлове от `.claude/commands/` работи същият frontmatter, **освен `name` и `paths`** – те там се игнорират.

Отделно за `allowed-tools`: това е **предварително одобрение за един ход**, а не ограничение. Разрешението отпада с вашето следващо съобщение, въпреки че съдържанието на скила остава в контекста. И има неприятно свойство, което трябва да знае всеки, който пуска агент в чуждо хранилище: **доверието към папката не го ограничава.** Проектният скил ще приложи своя `allowed-tools` и в папка, която никога не сте отбелязвали като доверена, включително при неинтерактивно стартиране. Тоест скил, който се намира в хранилището, може да си даде широки права – четете това поле в чужди хранилища, преди да стартирате.

#### Аргументи: номерация от нула

Най-неочакваното място в цялата тема, и си струва да се запомни дословно.

| Заместване | Какво се подставя |
|---|---|
| `$ARGUMENTS` | Целият низ с аргументи, както сте го въвели |
| `$ARGUMENTS[N]` | Аргумент по индекс, **индексацията е от нула** |
| `$N` | Кратка форма: `$0` – първият аргумент, `$1` – вторият |
| `$име` | Аргумент от списъка `arguments` във frontmatter, по позиция |

Да, `$0` е първият аргумент, а не името на командата, както в шела. Грешката с единица е най-честата тук.

Индексираните аргументи се разбират с отчитане на кавичките: в `/my-skill "hello world" second` стойността на `$0` е целият `hello world`. Индексирано заместване, за което не е стигнал аргумент, остава в текста както е; именуваното се превръща в празен низ. Ако в стойността на аргумент се окаже самият `$1` или `$ARGUMENTS`, той се вмъква буквално и втори път не се разгъва. Екранирането е с една обратна наклонена черта: `\$1.00`. И ако нито едно заместване в тялото не е получило аргументи, редът `ARGUMENTS: <стойност>` просто се дописва накрая.

#### Вградени команди на шела

Записът ``!`команда` `` се изпълнява **преди** съдържанието да стигне до модела и се заменя със собствения си изход. Така в скила се подава актуално състояние: клонът, diff-ът, списъкът с паднали тестове. С какво точно да се изпълнява – `bash` или `powershell` – се задава от полето `shell` във frontmatter.

Има две правила, които спестяват половин час недоумение. Записът се разпознава, **само ако `!` е в началото на реда или веднага след интервал** – в ``KEY=!`cmd` `` тя ще остане текст и няма да се изпълни. И заместването минава през файла веднъж: изходът на командата повторно не се сканира, затова командата не може да изведе друго заместване с надеждата за втори пас.

За многоредов скрипт се отваря блок с код с удивителен знак след трите обратни кавички.

Всичко това се изключва с ключа `disableSkillShellExecution`: всяка команда се заменя със съобщение, че е забранена от политиката. Действа върху потребителските, проектните, плъгинните скилове и скиловете от добавените папки; вградените и корпоративните не ги засяга. Скиловете, синхронизирани с claude.ai, никога не изпълняват такива команди локално, независимо от настройката.

#### Променливи за пътища

Вътре в тялото на скила и **вътре в правилата на `allowed-tools`** се подставят `${CLAUDE_SKILL_DIR}` – папката на самия скил, `${CLAUDE_PROJECT_DIR}` – коренът на проекта, `${CLAUDE_SESSION_ID}`, а в плъгинните скилове още `${CLAUDE_PLUGIN_ROOT}` и `${CLAUDE_PLUGIN_DATA}`.

Това, че работят и на двете места, не е дреболия, а работен похват: така скилът стартира собствения си скрипт без нито един въпрос за права.

```markdown title=".claude/skills/render/SKILL.md"
---
name: render
description: Изобразява схема от изходния файл
allowed-tools: Bash(${CLAUDE_SKILL_DIR}/scripts/render.sh *)
---

Стартирай `${CLAUDE_SKILL_DIR}/scripts/render.sh $0` и покажи резултата.
```

Правилото разрешава точно онази команда, която тялото указва да се изпълни – нито по-широко, нито по-тясно.

#### Дреболии, които е полезно да знаете

**Скиловете се комбинират.** В началото на едно съобщение може да се поставят до шест команди: `/write-tests /fix-issue 123` ще зареди двата скила и ще подаде `123` и на двата като аргумент. До версия 2.1.199 се зареждаше само първият, а останалото се считаше за текст. Изключение е `/code-review`, която си взема остатъка от реда.

**`ultrathink` в тялото на скила** моли модела да мисли по-дълбоко, когато скилът се задейства. Работи направо като дума в текста.

**Имената на вградените команди са запазени**, дори в сесията ви да са недостъпни: скил с конфликтно име, дошъл от синхронизация, ще бъде пропуснат.

**Скил може да се провери и без плъгин**: `claude plugin validate <път>` работи и върху обикновена папка със скилове и агенти. А за да стане папката със скилове плъгин, достатъчно е да сложите в нея `.claude-plugin/plugin.json`.

## Настройки: `settings.json`

По-нататък са ключовете на файла с настройки, включително експериментални и корпоративни, с типове и примери. Списъкът е съставен от два източника: официалния справочник за настройките, където сега има около двеста и двадесет записа, и схемата за валидация вътре в самия CLI. Те не съвпадат: в схемата има ключове, които ги няма в документацията, и обратното – в документацията има ключове, които схемата не познава, защото живеят в друг файл. За това – отделно по-долу.

Означения: **[експ]** – експериментален или вътрешен ключ, може да се промени или да изчезне; **[админ]** – действа само от корпоративен източник; **[остар]** – остарял; **[глобален]** – живее не в `settings.json`, а в `~/.claude.json`.

### Къде се намира файлът

Нивата не са четири и не са пет, а повече, отколкото обикновено се пише. Да започнем с обикновените:

| Ниво | Файл | Предназначение |
|---|---|---|
| Потребителско | `~/.claude/settings.json` | Лични настройки за всички проекти |
| Проектно | `<проект>/.claude/settings.json` | Екипни, комитват се в хранилището |
| Локално | `<проект>/.claude/settings.local.json` | Лични за конкретен проект, в `.gitignore` |
| Команден ред | `--settings <файл или JSON>` | Само за едно стартиране |
| Политика | зависи от системата | Корпоративна политика |
| Глобална конфигурация | `~/.claude.json` | Настройки, които в `settings.json` се игнорират |

**Последният ред е онова, което го няма почти никъде.** Част от настройките живеят само в `~/.claude.json` и ако ги напишете в `settings.json`, ще бъдат тихо пренебрегнати. Там Claude Code слага и сесията ви за вход, конфигурацията на MCP сървърите и решенията за доверие към папки. Обикновено този файл се пише сам и рядко се бърка ръчно в него – но трябва да знаете за него, защото „зададох ключа и нищо не стана“ най-често се обяснява точно с това.

Корпоративната политика също не е една. Източниците са четири и са наредени по ранг:

| Ранг | Източник |
|---|---|
| 1 | Сървърни настройки от claude.ai или корпоративен шлюз |
| 2 | Политика на операционната система: домен за управлявани настройки в macOS, ключ в регистъра `HKLM\SOFTWARE\Policies\ClaudeCode` в Windows |
| 3 | Файл с управлявани настройки: `/Library/Application Support/ClaudeCode/managed-settings.json`, `/etc/claude-code/managed-settings.json`, `C:\Program Files\ClaudeCode\managed-settings.json` |
| 4 | Същият ключ в регистъра, но в `HKCU` – достъпен за писане на самия потребител, затова не се смята за административен и се прилага само там, където по-горе няма нищо |

Политиката от системата и `HKCU` се прочита наново на всеки половин час, сървърните настройки – веднъж на час. По подразбиране източниците **не се събират**: прилага се най-старшият, останалите се отхвърлят. Това може да се промени с ключа `managedSourcesBehavior: "merge"`, но той трябва да се зададе в най-старшия от внедрените източници – долният не може сам да поиска сливане, а `HKCU` не се слива никога.

Ако админът е сложил нещо, а то „не е стигнало“ – вижте в `/status`: от версия 2.1.243 там има ред за пропуснатите източници, където направо пише кой файл е игнориран.

### Формат: строг JSON

Тук трябва да поправя самия себе си, защото преди мислех другояче и в интернет това се повтаря често.

**Файловете с настройки са строг JSON.** Коментар `//` или висяща запетая е синтактична грешка и при следващото стартиране файлът ще бъде отбелязан като грешен изцяло. Никакъв JSONC. (Объркването възниква, защото JSONC в продукта наистина има на други места – например `/terminal-setup` разбира конфигурацията на редактора с коментари.)

Най-лесно е да проверите файла си със стартиране: грешките в настройките се печатат при старта. `claude doctor` ще ги покаже с разбор.

Полезен навик е редът `$schema`:

```json title=".claude/settings.json"
{
  "$schema": "https://json.schemastore.org/claude-code-settings.json"
}
```

Редакторът започва да подсказва имената на ключовете и да подчертава правописните грешки, а грешка в името на ключ е най-честата причина настройката да „не работи“: неизвестните ключове се игнорират тихо. Уточнение: схемата понякога изостава от продукта. Например `teammateDefaultModel` в нея още го има, а от Claude Code е премахнат във версия 2.1.234 и на нищо не влияе.

### Кой кого припокрива

Редът на нивата е този от таблицата по-горе. Но „припокрива“ не е вярно за всичко, и ето три изключения, които чупят интуицията.

**Списъците се събират, а не се заменят.** Ако `permissions.allow` е зададен и в потребителския, и в проектния файл, ще получите обединението на двата. По-горното ниво **не може да премахне** запис на по-долното – единственото, което го може, е корпоративният `allowManagedPermissionRulesOnly`. Всяка таблица с приоритети, в която пише „всяко следващо припокрива предишното“, за списъците е невярна.

Четири списъка се държат иначе: `fallbackModel` се взема изцяло от най-старшия файл, който го определя (това е наредена верига, смесването ѝ няма смисъл); `modelPicker` – изцяло от най-старшия сред корпоративния, `--settings` и потребителския, а в проектния и локалния се игнорира; `availableModels` от админа се прилага както е, без да поема вашите добавки; `modelSettings` се разрешава поотделно за всеки модел.

**При седем ключа строгата стойност отдолу побеждава корпоративната.** Обикновено политиката е абсолютна – не я бие дори `--settings`. Но за тези ключове по-строгият вариант от всяко ниво печели, защото да си забраните излишното никой няма да ви пречи: `disableClaudeAiConnectors` със стойност `true`, `enableArtifact` със стойност `false` (и `disableArtifact: true`), `isolatePeerMachines` със стойност `true`, `remoteControlAtStartup` със стойност `false` от проектния или локалния файл, `crossSessionInbound` с по-строга стойност по скалата „приемане – задържане – отказ“, `useAutoModeDuringPlan` и `syncClaudeAiSkills` със стойност `false`.

**Проектните разрешения чакат доверие към папката.** `permissions.allow` и `permissions.additionalDirectories` от проектния файл започват да действат едва след като потвърдите доверие към тази папка. `deny` и `ask` действат веднага – те само ограничават.

А ето най-важното и това трябва да го прочете всеки, който стартира `claude -p` в чуждо хранилище. **В неинтерактивен режим диалогът за доверие не се показва**, затова проектните разрешаващи правила се отхвърлят с предупреждение в потока за грешки – **но хуковете на това хранилище се изпълняват, блокът му `env` се прилага, помощните му скриптове за авторизация се стартират, полето `allowed-tools` на скиловете му действа, а сървърите от неговия `.mcp.json` се свързват без въпроси.** Отхвърлят се именно разрешенията, а не изпълнимите части.

Безопасното стартиране в непроверена папка е `--setting-sources user`, `--bare`, `--restricted` или `--settings '{"disableAllHooks": true}'`. Просто да зададете `disableAllHooks` в личния си файл **не е достатъчно**: проектният файл е по-старши и ще го върне обратно.

### Променливите на средата не са ниво

Още нещо, което обикновено се рисува неправилно. Променливите на средата не стоят „между“ нивата на настройките: кой кого припокрива, се решава **за всяка двойка „променлива – ключ“ поотделно**.

- `ANTHROPIC_MODEL` от шела припокрива ключа `model` от всеки файл.
- `ANTHROPIC_DEFAULT_MODEL` действа само ако `model` не е зададен никъде.
- `--model` и `/model` припокриват `ANTHROPIC_MODEL`.
- А `CLAUDE_CODE_EFFORT_LEVEL` е устроен обратно и припокрива `--effort` и `/effort`.

И отделно: **стойността от блока `env` в настройките побеждава експорта от шела**, а не обратното, както е прието да се мисли. Claude Code записва всеки запис от блока в средата на процеса върху наследената стойност. Променлива не може да се премахне от файла с настройки – може да се зададе празен низ, което при избора на доставчик се смята за „не е зададена“ (макар дъщерните процеси да получат празна стойност). Променливите на шела се четат веднъж при старта, а стойностите от `env` се прочитат наново при промяна на файла – освен подсистемите, които се настройват само при стартиране, като телеметрията.

### Скелет на файла

Скаларите като `model`, `theme`, числата и флаговете се пишат на най-горното ниво. Групираните настройки – `permissions`, `env`, `hooks`, `statusLine`, `worktree`, `voice`, `sandbox`, `sshConfigs` – са вложени обекти.

```json title=".claude/settings.json"
{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "model": "opus",
  "outputStyle": "default",
  "theme": "dark",
  "autoCompactEnabled": true,
  "cleanupPeriodDays": 30,
  "includeCoAuthoredBy": false,
  "env": {
    "CLAUDE_CODE_USE_POWERSHELL_TOOL": "1",
    "DISABLE_TELEMETRY": "1"
  },
  "permissions": {
    "allow": ["Bash(npm run build)", "Edit(src/**)"],
    "ask": ["Bash(git push:*)"],
    "deny": ["Read(./.env)"],
    "defaultMode": "acceptEdits",
    "additionalDirectories": ["../shared-lib"]
  },
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{ "type": "command", "command": "npm run lint" }]
      }
    ]
  },
  "statusLine": {
    "type": "command",
    "command": "~/.claude/statusline.sh",
    "padding": 1
  },
  "worktree": {
    "symlinkDirectories": ["node_modules"],
    "baseRef": "fresh"
  },
  "enabledPlugins": {
    "formatter@anthropic-tools": true
  }
}
```

### Автентикация и доставчици

| Параметър | Тип | Какво прави |
|---|---|---|
| `apiKeyHelper` | низ, път към скрипт | Скрипт, който печата в стандартния изход стойност за авторизация. Удобно за временни и ротирани ключове. |
| `proxyAuthHelper` | низ, команда | **[експ]** Команда, която печата стойността на хедъра за авторизация на проксито. |
| `awsCredentialExport` | низ, път | Скрипт, който експортира идентификационните данни на AWS за Bedrock. |
| `awsAuthRefresh` | низ, път | Скрипт, който обновява автентикацията в AWS преди изтичане на срока. |
| `gcpAuthRefresh` | низ, команда | Команда за обновяване на автентикацията в Google Cloud. |
| `otelHeadersHelper` | низ, път | Скрипт, който печата HTTP хедъри за експорта на телеметрия. |
| `policyHelper` | обект | **[админ]** Изпълним файл, който изчислява настройките на политиката при старт: `path`, `timeoutMs`, `refreshIntervalMs`. |
| `policyHelpers` | обект по системи | **[админ]** Същото, но отделно за macOS, Linux, Windows и WSL. |
| `forceLoginMethod` | `claudeai`, `console`, `gateway` | Твърдо задава начина на вход: абонамент, билинг през Console или корпоративен шлюз. |
| `forceLoginOrgUUID` | низ или масив | **[админ]** Разрешава вход само в посочената организация или в някоя от списъка. |
| `forceLoginGatewayUrl` | низ, адрес | **[админ]** Задължителен адрес на корпоративния шлюз за вход. |
| `forceRemoteSettingsRefresh` | boolean | **[админ]** Блокира стартирането, докато не бъдат изтеглени свежи настройки на политиката. |
| `parentSettingsBehavior` | `first-wins`, `merge` | **[админ]** Как родителският слой от SDK се съчетава с админския. |
| `xaaIdp` | обект | **[експ]** Свързване на външен доставчик на идентичност: `issuer`, `clientId`, `callbackPort`. |

Стойността `gateway` на `forceLoginMethod` се взема предвид само от източник, намиращ се на самата машина: файл на политика, домен на настройките на macOS или клон `HKLM`. В потребителския, проектния, локалния и в `HKCU` се смята за незадена – иначе корпоративният вход би могъл да се пренасочи от хранилището.

### Модел, мислене, усилия

| Параметър | Тип | Какво прави |
|---|---|---|
| `model` | низ | Модел по подразбиране: псевдоним или пълен идентификатор. |
| `availableModels` | масив от низове | **[админ]** Бял списък с модели. Празен масив – само моделът по подразбиране. |
| `enforceAvailableModels` | boolean | **[админ]** Разпростира белия списък и върху реда „по подразбиране“ в избора на модел. |
| `modelOverrides` | обект | **[админ]** Съответствие между идентификаторите на Anthropic и идентификаторите на доставчика. |
| `modelPicker` | обект | Собствен списък в `/model`: записи `{model, label, description}`; `replaceBuiltInOptions` заменя вградения. |
| `modelSettings` | обект | Настройки, вързани за конкретен модел – засега нивото на усилие. |
| `modelPricing` | обект | **[админ]** Тарифи на организацията вместо ценоразписа: множител на отстъпката и единични цени. |
| `advisorModel` | низ | Модел за съветника. |
| `agent` | низ | Име на агента за главния поток: неговият системен промпт, ограничения и модел. |
| `alwaysThinkingEnabled` | boolean | `false` изключва размишленията. |
| `showThinkingSummaries` | boolean | Показва обобщения на размишленията в диалога и в транскрипта. |
| `effortLevel` | `low`, `medium`, `high`, `xhigh` | Запазено ниво на усилие. **`max` схемата не приема.** |
| `ultracode` | boolean | **[експ]** `xhigh` плюс постоянна оркестрация на workflow-и. |
| `fastMode` | boolean | Дали е включен ускореният режим на генериране. |
| `fastModePerSessionOptIn` | boolean | Да не се запазва fast режимът между сесиите. |
| `autoCompactEnabled` | boolean | Автоматично свива разговора при запълване на контекста. |
| `autoCompactWindow` | число 100000–1000000 | Размер на прозореца за автосвиване в токени. |
| `precomputeCompactionEnabled` | boolean | Подготвя свиването предварително, докато върви работата. |
| `switchModelsOnFlag` | boolean | При задействане на филтъра за сигурност превключва към друг модел. **По подразбиране `true`.** |
| `fallbackModel` | масив от низове | Модели за връщане назад при претоварване на основния; пробват се по ред. |
| `promptCacheTtl` | `5m`, `1h` | Време на живот на кеша на промпта на основния разговор. |
| `subagentPromptCacheTtl` | `5m`, `1h` | Същото за субагентите; по подразбиране пет минути. |

Три стойности по подразбиране, които променят поведението и за които рядко се пише.

`switchModelsOnFlag` е включен. Тоест при задействане на филтъра за сигурност моделът тихо се сменя, за да не се прекъсва диалогът. Ако го изключите, интерактивната сесия ще спре и ще ви попита, а неинтерактивното стартиране ще завърши заявката с грешка – за скриптове това често е по-правилно, защото тихата подмяна на модела в CI изглежда като необяснима промяна в поведението.

`promptCacheTtl` се подбира сам: час при абонамент, иначе пет минути. Променливата на средата го припокрива.

`effortLevel` не приема `max` умишлено, за да не остава максималното ниво включено завинаги; за сесията се задава с команда или флаг.

### Права за достъп на инструментите

Най-практически важната част от файла – и най-подценената по броя подводни камъни. Вложеният обект `permissions`:

| Поле | Тип | Какво прави |
|---|---|---|
| `allow` | масив от правила | Какво е разрешено без въпроси. |
| `deny` | масив от правила | Какво е забранено винаги. |
| `ask` | масив от правила | Какво винаги изисква потвърждение. |
| `defaultMode` | вж. по-долу | Режим по подразбиране. |
| `disableBypassPermissionsMode` | `"disable"` | Забранява режима на заобикаляне на потвържденията. |
| `additionalDirectories` | масив от пътища | Допълнителни директории в обхвата на достъп. |

Наред с тях са ключовете от най-горното ниво: `skipDangerousModePermissionPrompt` и `skipAutoPermissionPrompt` помнят, че вече сте приели съответното предупреждение; `allowManagedPermissionRulesOnly` **[админ]** нарежда да се вземат предвид само списъците от политиката; `disableAutoMode` изключва авто режима; `useAutoModeDuringPlan` позволява да се прилага в режим на планиране, по подразбиране – да.

#### Режими

| Режим | Какво прави |
|---|---|
| `default` | Обикновен: пита, когато е нужно. Псевдоним – `manual`, от версия 2.1.200 се приема и в настройките |
| `acceptEdits` | Автоматично приема промените във файловете |
| `plan` | Само анализ, нищо не се променя |
| `auto` | Решението се взема от класификатор |
| `dontAsk` | **Автоматично отказва всичко, което би изисквало въпрос** |
| `bypassPermissions` | Приема всичко |

**`dontAsk` не значи „не питай за дреболии“.** Това е най-опасното недоразумение в цялата тема за правата и аз самият го повтарях. Режимът не смекчава, а затяга: всичко, което в обикновения режим би породило въпрос, **се забранява автоматично**. Работи само онова, което е попаднало в `allow`, вграденият набор от безопасни команди за четене и онова, което е одобрил хук. Вашите собствени правила `ask` в този режим не питат, а отказват; въпросът на агента към вас също се отхвърля, дори да е разрешен.

Още една тънкост: стойността `auto` **не действа от проектните и локалните настройки** – трябва да се зададе в потребителския файл. А сесиите, стартирани от разширението за VS Code, четат само потребителския, корпоративния и `--settings`.

#### Формат на правилото

Правилото се записва като `Инструмент(уточнение)`: `Bash(npm run build)`, `Edit(src/**)`, `Read(~/.zshrc)`.

```json title=".claude/settings.json"
{
  "permissions": {
    "allow": ["Bash(npm run:*)", "Edit(src/**)", "Read(~/.config/**)"],
    "ask": ["Bash(git push:*)"],
    "deny": ["Read(./secrets/**)", "Read(./.env)"],
    "defaultMode": "acceptEdits",
    "additionalDirectories": ["../shared", "/tmp/workspace"]
  }
}
```

Изглежда просто. По-нататък са дванадесет правила за поведение, всяко от които обяснява някой популярен въпрос „защо правилото ми не работи“.

#### Ред на проверка: първо забрана, после въпрос, после разрешение

Правилата се проверяват в строго определен ред – `deny`, после `ask`, после `allow` – и **печели първото съвпадение, а не най-точното**. Оттук две следствия, които чупят очакванията.

Широката забрана припокрива тясното разрешение: `deny` с `Bash(aws *)` ще блокира `allow` с `Bash(aws s3 ls)`. Изключения от забраната няма – механизъм „забрани всичко освен“ тук няма.

Съвпаднало `ask` пита, дори да има по-точно `allow`. Това не е грешка, това е начин да кажете „тази команда винаги я потвърждавам ръчно“, и работи върху всякакви разрешения.

Между нивата на настройките е същото: забрана от потребителския файл бие разрешение от проектния и обратно, защото всички `deny` от всички нива се проверяват преди всяко `allow`.

Още една дреболия с големи последствия: **голо име на инструмент в `deny` премахва инструмента от контекста изцяло.** Записът `"Bash"` в забраните означава, че агентът изобщо няма да научи за този инструмент. А `Bash(rm *)` оставя инструмента видим и забранява само съвпадащите извиквания.

#### Защитените пътища се проверяват преди вашите правила

Съществува списък с пътища, записът в които се проверява **преди** да се погледне `allow`. Затова `Edit(.claude/**)` във всеки файл с настройки не дава съвсем нищо – и това е най-честият източник на въпроса „защо разрешението ми се игнорира“.

В списъка със защитени каталози са: `.git`, `.config/git`, `.vscode`, `.idea`, `.husky`, `.cargo`, `.devcontainer`, `.yarn`, `.mvn` и `.claude` изцяло, освен `.claude/worktrees`. От файловете – `.gitconfig`, `.gitmodules`, всички файлове на профили и стартиране на шела, `.envrc`, `.npmrc`, `.yarnrc*`, `.pnp.cjs`, `bunfig.toml`, `.bazelrc`, `.pre-commit-config.yaml`, `lefthook.*`, `gradle-wrapper.properties`, `.ripgreprc`, `pyrightconfig.json`, `.mcp.json` и `.claude.json`.

Логиката е ясна: всичко това са файлове, чиято промяна променя поведението на самата ви машина при следващата команда, чак до това, че ще се изпълни нещо вместо `git commit`. Какво ще стане при опит, зависи от режима: обикновеният и `acceptEdits` ще попитат, `plan` ще позволи само ако е достъпно заобикалянето, `auto` ще го предаде на класификатора, `dontAsk` ще откаже, `bypassPermissions` ще позволи. В диалога има и отделна опция – да разрешите промяна на собствените си настройки за тази сесия.

#### Предпазител при изтриване

`rm` и `rmdir`, насочени към критични пътища, **не се одобряват с нищо**: нито с правило в `allow`, нито с хук, върнал разрешение.

Критичните пътища са коренът на файловата система и всеки негов пряк потомък, домашната папка, корените на дисковете в Windows и техните каталози от първо ниво, текущата работна папка и нейните родители, както и шаблоните вътре в добавените директории.

Най-интересна е таблицата по режими, защото е устроена не така, както всички очакват:

| Режим | Какво ще стане |
|---|---|
| обикновен, `acceptEdits`, `plan` | Ще попита |
| `auto` | Ще го предаде на класификатора |
| `dontAsk` | Ще откаже |
| `bypassPermissions` | **Ще попита** |

Тоест режимът „заобикаляй всички потвърждения“ тук е **по-строг** от авто режима: `--dangerously-skip-permissions` на такова изтриване въпреки това ще спре.

Брои се и онова, което изглежда безобидно: `rm -rf "$DIR"/*` попада под предпазителя, защото празната променлива го превръща в изтриване от корена. Скриването на командата в заместване, обратни кавички или заместване на процес няма да помогне – проверката ги вижда.

#### Четири котви на пътя

Правилата `Read` и `Edit` използват синтаксиса на `.gitignore` и в него има четири различни начина да се закачи път. Постоянно ги бъркат.

| Запис | Към какво е вързан |
|---|---|
| `//път` | Коренът на файловата система |
| `~/път` | Домашната папка |
| `/път` | **Източникът на настройките**, а не коренът на диска |
| `път` или `./път` | Текущата работна папка |

Третият ред е капан. Единична наклонена черта в началото **не означава абсолютен път**: тя вързва правилото към онзи файл с настройки, където е написано. Правилото `Read(/secrets/**)` в `~/.claude/settings.json` означава `~/.claude/secrets/**`, а съвсем не `secrets` във вашия проект. В проектните настройки същата черта се отчита от основната работна папка, в `--settings` – от папката на посочения файл, а правилата от локалните настройки от версия 2.1.211 са вързани за работната папка на сесията, а не за корена на хранилището – тоест в отделно работно копие `Edit(/src/**)` ще попадне в собствения му `src`.

Голото име на файл се държи като в `.gitignore` и съвпада на всяка дълбочина: `Read(.env)` е същото като `Read(**/.env)`. А `Read(//**/.env)` е вързано за корена на файловата система.

В Windows пътищата се привеждат към POSIX вид преди сравнението: `C:\Users\alice` се превръща в `/c/Users/alice`. Затова правилото за всички дискове се пише като `//**/.env`, а за конкретен – `//c/**/.env`.

#### Едно и също правило хваща различна дълбочина в `allow` и в `deny`

Едносегментният относителен шаблон на папка се държи асиметрично и това е нарочно.

`Edit(src/**)` в `allow` съвпада само с папката `src` в корена на работната директория. Същото в `deny` или `ask` съвпада с папката `src` **на всяка дълбочина** – тоест хваща и `vendor/pkg/src/lib.js`.

Смисълът е ясен: разрешението трябва да е тясно, забраната – широка. Всички останали форми се държат еднакво във всеки тип правила: `Edit(/src/**)` и `Edit(src/components/**)` съвпадат само там, където са написани, `Edit(**/src/**)` – навсякъде. Поведението се промени във версия 2.1.214: до нея `Edit(src/**)` хващаше всяка дълбочина и в разрешенията.

#### Двоеточие само в края, а интервалът пред звездичката е значим

Формата `Bash(ls:*)` е точно същото като `Bash(ls *)`. Но се разпознава **само в края на шаблона**: в `Bash(git:* push)` двоеточието е обикновен символ и правилото няма да съвпадне с нищо.

Интервалът пред звездичката е част от правилото. `Bash(ls *)` изисква интервал и затова не съвпада с `lsof`; `Bash(ls*)` – съвпада. Завършващата звездичка хваща и голата команда без аргументи, но само ако е единствена в правилото: `Bash(ls *)` ще съвпадне с `ls`, а `Bash(* --help *)` ще съвпадне с `npm --help x` и няма да съвпадне с `npm --help`.

Всичко, което стои пред първата звездичка, се сравнява буквално. Оттук и неприятността: `Bash(git * main)` разрешава **всяка** подкоманда на git, включително `-c` с произволна конфигурация. От версия 2.1.246 за разрешаващите правила със звездичка пред подкомандата при стартиране се печата предупреждение.

#### Съставни команди

Разделителите, които Claude Code разбира: `&&`, `||`, `;`, `|`, `|&`, `&` и нов ред. **Всяка част трябва да съвпадне с правило поотделно** – общо разрешение за целия ред няма.

Отделен случай: ако операторът е в края и след него няма нищо – например `npm test &&` – командата се смята за неразбираема и **изобщо не се дели**. Тогава дори `Bash(npm *)` няма да я одобри.

Когато отговорите „да, и повече не питай“ на съставна команда, се запазва **отделно правило за всяка част**, за която е било нужно. Преминаването в подпапка ще породи собствено правило за четене. Повече от пет правила от една команда не се запазват.

Пренасочванията на изхода `>`, `>>`, `2>` се проверяват като запис във файл – спрямо вашите правила `Edit`, списъка със защитени пътища и работните директории. `/dev/null` е изключен от проверката; цел, започваща с `~` или съдържаща шаблон, изисква потвърждение винаги.

#### Кои обвивки се свалят и кои не

Преди да се сравни с правилата, от командата се махат: `timeout`, `time`, `nice`, `nohup`, `stdbuf`, вградените `command` и `builtin`, `noglob` от zsh и голият `xargs` – последният само без флагове, `xargs -n1 grep` се разбира като команда `xargs`.

Свалява се и водещото присвояване на позната безопасна променлива, затова `Bash(npm test *)` ще съвпадне с `NODE_ENV=test npm test`. Разрешаващото правило не минава през присвояване на каквато и да е друга променлива, а забраняващото минава през всяка.

**Списъкът е фиксиран и не се настройва.** И в него няма нито един стартер на среда: `npx`, `docker exec`, `direnv exec`, `devbox run`, `mise exec` не се свалят. Практически извод: `Bash(devbox run *)` е разрешение за `devbox run rm -rf .`, защото за проверката това е команда `devbox`, а не `rm`.

Отделно има команди, които не могат да се одобрят с префиксно правило никога: `watch`, `setsid`, `ionice`, `flock`, а също `find` с `-exec` или `-delete`. В обикновения режим те ще питат винаги.

#### Правилата за `Write`, `Glob`, `NotebookEdit` и `MultiEdit` се приемат и не работят

Файловите права се проверяват **само** спрямо правилата `Edit(...)` и `Read(...)`. Правило от вида `Write(docs/**)` или `Glob(docs/**)` ще бъде разпознато, запазено, показано в `/permissions` – и никога използвано. От версия 2.1.210 за такова нещо при стартиране се печата предупреждение.

Пишете `Edit(...)` вместо `Write`, `NotebookEdit` и `MultiEdit` и `Read(...)` вместо `Glob`. Голото име на инструмента без път работи: `Write` може да се забрани изцяло.

Полезно следствие: забраняващо правило `Read` за път блокира и редактирането, и записването в него – но не и `NotebookEdit`.

#### Символични връзки

Всяко обръщение към файл се проверява едновременно по два пътя: по самата връзка и по онова, накъдето води. Правилата тук са асиметрични.

Разрешението действа, само ако съвпаднат **и двата** пътя. Затова връзка вътре в разрешена папка, водеща навън, все пак ще попита.

Забраната действа, ако съвпадне **поне единият**. Затова връзката към забранен файл е забранена сама.

На практика: ако е разрешено `Read(./project/**)` и забранено `Read(~/.ssh/**)`, то `./project/key`, който води към `~/.ssh/id_rsa`, ще бъде блокиран.

#### Правила по параметри на инструмента

Малко известно семейство. Забраняващите и питащите правила могат да съвпадат по скаларно поле от входните данни на инструмента:

```json title=".claude/settings.json"
{
  "permissions": {
    "deny": ["Agent(model:opus)", "Agent(isolation:worktree)", "Bash(run_in_background:true)"]
  }
}
```

Един параметър на правило, вложени полета не се поддържат, `*` се подставя вместо стойност. Параметър, който моделът не е подал, не съвпада никога – тоест `Agent(model:opus)` няма да хване извикване, където моделът изобщо не е посочен. Стойността се сравнява с онова, което е дошло, **преди** нормализацията: псевдонимът `opus` ще съвпадне, а пълният идентификатор на същия модел – не.

Основното поле на инструмента по този начин не се съпоставя нарочно: `command`, `file_path`, `path`, `notebook_path`, `url` са изключени. Правилото `Bash(command:rm *)` се игнорира с предупреждение – твърде лесно би се заобиколило със съставна команда.

За MCP инструментите параметричните правила работят само през флага `--disallowedTools`: всяко правило с `mcp__` и скоби във файл с настройки се пропуска и попада в списъка с некоректни настройки и в изхода на `claude doctor`.

#### Шаблони в името на инструмента

В забраняващите и питащите правила името на инструмента може да се зададе с шаблон и той трябва да покрива името изцяло: `"*"` – всички инструменти, `"mcp__*"` – всички инструменти на MCP.

В разрешаващите правила шаблонът е допустим **само след буквален префикс `mcp__<сървър>__`**, при това името на сървъра трябва да е без шаблони. Тоест `mcp__github__get_*` работи, а `"*"`, `"B*"` и `"mcp__*"` в `allow` се пропускат с предупреждение и не разрешават нищо.

И още един капан: **името на инструмента на екрана може да се различава от каноническото.** Онова, което е показано като „Stop Task“, канонически се нарича `TaskStop`, и в правилата и във филтрите на хуковете работи само каноничното име.

#### `WebFetch` – две различни правила с подобен вид

Голото `WebFetch` и `WebFetch(domain:*)` не са едно и също, защото втората форма заедно с това променя списъка с домейни на пясъчника.

| Правило | Какво прави |
|---|---|
| `allow: WebFetch` | Зарежда страници без въпроси, но не разширява пясъчника – `curl` от пясъчника към същия хост все пак ще попита |
| `allow: WebFetch(domain:*)` | Плюс разрешава на пясъчника мрежов достъп |
| `deny: WebFetch` | Премахва инструмента изцяло |
| `deny: WebFetch(domain:*)` | Инструментът остава, всяко зареждане се отхвърля, мрежата на пясъчника е затворена |

Шаблони в домейна: `*.example.com` хваща поддомейни на всяка дълбочина, но **не и самия** `example.com`. На всяка друга позиция звездичката съвпада само с текста между две точки – `example.*` ще хване `example.org` и няма да хване `example.evil.com`.

И една трезва забележка: докато агентът има достъп до шела, разрешенията на `WebFetch` не ограничават мрежовия достъп по никакъв начин.

#### Вграден набор от безопасни команди

Част от командите се изпълняват без въпрос **във всеки** режим и този списък е зашит: `ls`, `cat`, `echo`, `pwd`, `head`, `tail`, `grep`, `find`, `wc`, `which`, `diff`, `stat`, `du`, `cd` и read-only формите на `git`. Не може да се разшири, може само да се припокрие със свое правило `ask` или `deny`.

Но и той ще попита, ако: в команда, която има флагове за запис или стартиране (`find`, `sort`, `sed`, `git` – шаблонът би могъл да се разгърне в `-delete`), е срещнат шаблон без кавички; при `docker` има `-H`, `--context`, `--url` или `--connection`; при `file` има `-m`, `--magic-file`, `-f` или `--files-from`; в аргументите има мрежов път на Windows; командата е по-дълга от десет хиляди знака или не се разбира. Освен това `cd` заедно с `git` ще попита, ако папката наистина се сменя – в новата папка може да има свои хукове на git.

#### PowerShell

Правилата за PowerShell са устроени по същия начин, сравняват се без отчитане на регистъра и **привеждат популярните псевдоними към канона**: `PowerShell(Get-ChildItem *)` ще съвпадне и с `gci`, и с `ls`, и с `dir`. Командата се разбира по синтактичното дърво и се дели по `|`, `;`, а в седма версия още и по `&&` и `||`; всяка част се проверява поотделно.

`Remove-Item` има своя проверка, **по-строга от тази на `rm`**: системните пътища и целите с шаблон – гола `*`, всичко, което завършва на `/*` или `\*`, включително `$dir/*`, – се забраняват във всички режими без въпрос, още преди класификатора. По обикновените правила на режима минава само случаят „работната папка или нейният родител с рекурсия“, и именно за него режимът за заобикаляне на потвържденията премахва въпроса.

И отделно за Windows: всяка команда, в чиито аргументи има мрежов път от вида `\\сървър\ресурс\файл`, ще поиска потвърждение, дори в останалото да е безобидна, – такъв път може да отмъкне идентификационните данни на Windows.

### Авто режим

От версия 2.1.283 това е **режимът по подразбиране** за интерактивните сесии в терминала и VS Code при всички планове; в по-ранните версии – само при Pro, Max, Ultra и Team. Решението за всяко действие се взема от класификатор, а не от списък с правила, и се настройва с отделен обект `autoMode`.

| Поле | Тип | Какво прави |
|---|---|---|
| `autoMode.environment` | масив от низове | Какво класификаторът трябва да знае за вашата среда. Това попълва и `/auto-mode-setup`. |
| `autoMode.allow` | масив от низове | Какво пропуска. |
| `autoMode.soft_deny` | масив от низове | За какво ви пита. |
| `autoMode.hard_deny` | масив от низове | Какво забранява без въпроси. |
| `autoMode.classifyAllShell` | boolean | Дали да прекарва през класификатора изобщо всички команди на шела. По подразбиране – не. |

Три неща, които тук са по-важни от самата таблица.

**Редът `"$defaults"` е задължителен почти винаги.** Във всеки от четирите списъка той добавя стандартния набор правила. Ако не го напишете, **целият вграден списък на тази секция тихо изчезва** – заедно с меките блокове за форс-пуш, за `curl | bash`, за внедряване в продукция и за заобикаляне на самия авто режим, и с твърдия блок за изтичане на данни. Вашите правила трябва да допълват набора, а не да го заменят.

**Тесните разрешения заобикалят класификатора.** Правило като `Bash(npm test)` в авто режима продължава да действа и се разглежда **преди** класификатора. Спират се само широките разрешения за произволно изпълнение – `Bash(*)`, интерпретатори със звездичка – и всички правила, назоваващи инструмент за наблюдение. Тоест тясно правило може да пропусне разрушителен аргумент, който никой не е погледнал. Затваря се с `classifyAllShell: true`, и тогава за времето на авто режима се изключват всички разрешаващи правила на шела.

**Класификаторът не чете настройките на проекта.** Взема `autoMode` само от потребителския файл, корпоративния и `--settings`. Иначе хранилището би могло да си подхвърли разрешения; локалните настройки се четяха до версия 2.1.207, сега вече не.

Конфигурацията може да се разгледа и разбере от терминала:

```bash
claude auto-mode config                       # какво действа и откъде идва
claude auto-mode defaults                     # стандартните правила на всичките четири списъка
claude auto-mode defaults --label 'Git Destructive'   # пълният текст на едно правило
claude auto-mode critique                     # разбор на вашите правила от модела
claude auto-mode reset --yes                  # връща стандартните без въпрос
```

Подкомандата `critique` е подценена: тя моли модела да анализира вашите собствени правила и да покаже онези, които са двусмислени, излишни или ще дават фалшиви задействания.

Режимът се изключва с ключа `disableAutoMode`, и тук има капан: **стойността трябва да е низът `"disable"`.** Масив или `true` схемата ще пропусне без грешка, но кодът сравнява именно с низ и режимът тихо ще остане включен. Съветникът за настройка може да се скрие със записа `"auto-mode-setup": "off"` в `skillOverrides`; `disableBundledSkills` не го изключва, защото това е вградена команда, а не скил.

### MCP сървъри

| Параметър | Тип | Какво прави |
|---|---|---|
| `enableAllProjectMcpServers` | boolean | Автоматично одобрява всички сървъри от `.mcp.json` на проекта. |
| `enabledMcpjsonServers` | масив от имена | Изрично одобрени сървъри от `.mcp.json`. |
| `disabledMcpjsonServers` | масив от имена | Изрично отхвърлени сървъри. |
| `allowedMcpServers` | масив от обекти | **[админ]** Бял списък: по име, команда или адрес. Празен масив – не е разрешен нито един. |
| `deniedMcpServers` | масив от обекти | **[админ]** Черен списък. С по-висок приоритет от белия. |
| `allowManagedMcpServersOnly` | boolean | **[админ]** Белият списък се чете само от политиката. |
| `allowAllClaudeAiMcps` | boolean | **[админ]** Зарежда облачните конектори заедно с управлявания списък. |
| `managedMcpServers` | масив от обекти | **[админ]** Самите сървъри, разпратени от администратора: транспорт, връзка и карта на разрешените инструменти. |

Последният ред поправя разпространено твърдение, което и аз самият преди повтарях: „сървърите се задават само в `.mcp.json`, а в настройките – само правата за тях“. Това е вярно за вас, но не и за администратора: `managedMcpServers` в корпоративните настройки съдържа именно конфигурациите на сървърите и се разгръща върху всички през файл на политика или система за управление на устройства.

Обикновените сървъри се задават в `.mcp.json` или през `claude mcp add`.

### Хукове

Хуковете са тема за отделна статия и аз [имам такава](/bg/claude-code-hooks/): там са разгледани всички събития, форматите за обмен и работни примери. Тук са ключовете на настройките и онова, което най-често се чупи.

`hooks` е обект от вида „събитие → масив от матчери“. Матчерът има филтър `matcher` и списък с обработчици.

```json title=".claude/settings.json"
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "npm run lint" },
          { "type": "command", "command": "echo", "args": ["done"] }
        ]
      }
    ]
  }
}
```

Събитията са трийсет и три. За инструментите: `PreToolUse`, `PostToolUse`, `PostToolUseFailure`, `PostToolBatch`. За разговора: `UserPromptSubmit`, `UserPromptExpansion`, `Stop`, `StopFailure`, `Notification`, `MessageDisplay`. За сесията: `SessionStart`, `SessionEnd`, `Setup`, `InstructionsLoaded`, `ConfigChange`. За свиването и смяната на модела: `PreCompact`, `PostCompact`, `PreModelSwitch`, `PostModelSwitch`. За правата: `PermissionRequest`, `PermissionDenied`. За субагентите и задачите: `SubagentStart`, `SubagentStop`, `TeammateIdle`, `TaskCreated`, `TaskCompleted`. За файловете и папките: `FileChanged`, `CwdChanged`, `DirectoryAdded`, `WorktreeCreate`, `WorktreeRemove`. И две за формите на MCP: `Elicitation`, `ElicitationResult`.

Обработчикът е от пет вида, видът се задава с полето `type`: `command` стартира програма или ред на шела, `prompt` пита малък бърз модел, `agent` изпраща пълноценен агент, `http` извиква адрес, `mcp_tool` извиква инструмент на MCP сървър. Общите незадължителни полета са `if` с условие, `timeout`, `statusMessage` за спинъра, `once` за еднократно изпълнение за сесия и `async` със свързаното `asyncRewake`.

| Параметър | Тип | Какво прави |
|---|---|---|
| `hooks` | обект | Самите хукове. |
| `disableAllHooks` | boolean | Изключва всички хукове и изпълнението на реда на състоянието. |
| `allowManagedHooksOnly` | boolean | **[админ]** Изпълнява само хукове от политиката. |
| `allowedHttpHookUrls` | масив от низове | **[админ]** Бял списък с адреси за HTTP хукове. |
| `httpHookAllowedEnvVars` | масив от низове | Кои променливи на средата HTTP хуковете могат да подставят в хедърите. |
| `disableSkillShellExecution` | boolean | Забранява вградените извиквания на шела в скиловете и в собствените команди. |

#### Три неща, заради които хукът „работи, но нищо не прави“

**Изходен код 1 нищо не блокира.** Блокира само код 2, и то само при около една трета от събитията. Единицата и всеки друг ненулев код при повечето събития са просто неблокираща грешка в журнала. Код 2 при това е по-силен от вашия собствен JSON: дори да сте върнали решение „разреши“, двойката ще забрани.

Къде двойката блокира: `PreToolUse`, `UserPromptSubmit` (изтривайки промпта), `UserPromptExpansion`, `Stop`, `SubagentStop`, `TeammateIdle`, `TaskCreated`, `TaskCompleted`, `ConfigChange`, `PostToolBatch`, `PreModelSwitch`. Къде се игнорира: `PermissionRequest` и `PermissionDenied` – там решават полетата на JSON, – и `StopFailure`. При `PostToolUse` двойката не блокира, а се показва на модела. При `WorktreeCreate` прекъсва **всеки** ненулев код. И отделна асиметрия: изтекъл таймаут при `PreToolUse` не блокира, а при `PreModelSwitch` – блокира.

**Изходът на хука моделът почти никога не го вижда.** Обикновеният текст в стандартния изход при код 0 попада в журнала за дебъгване, а не в разговора. На модела се показва точно при четири събития: `UserPromptSubmit`, `UserPromptExpansion`, `SessionStart` и `PostModelSwitch`. Потокът за грешки не се показва никъде и никога. При останалите събития нещо може да се предаде на модела само със структуриран отговор – поле за допълнителен контекст или системно съобщение. JSON при това се разбира само ако изходът започва с `{` и завършва с `}`.

**Филтърът понякога се игнорира изцяло, а понякога е регулярен израз.** `"*"`, празен низ или липса на полето означават „всички“. Филтър, състоящ се само от букви, цифри, `_`, `-`, интервали, запетаи и `|`, е точно съвпадение или изброяване. Всеки друг символ го превръща в регулярен израз, който се проверява **без привързване към началото и края**, ако не сте ги написали сами. Регистърът се отчита.

И филтърът не винаги е за името на инструмента. При `SessionStart` се сравнява с начина на стартиране, при `SessionEnd` – с причината за завършване, при свиването – с `manual` или `auto`, при `ConfigChange` – с това кой файл с настройки е променен, при `FileChanged` – с името на файла, при смяна на модела – с каноничното име на модела. А събитията `UserPromptSubmit`, `PostToolBatch`, `Stop`, `CwdChanged`, `TeammateIdle`, задачите, работните копия и `MessageDisplay` **изобщо не приемат филтър** и тихо игнорират написания.

Таймаутите по подразбиране са различни: при `command`, `http` и `mcp_tool` – десет минути, но при `UserPromptSubmit` и при събитията за смяна на модела трийсет секунди, а при `MessageDisplay` десет; при `prompt` – трийсет секунди, при `agent` – минута; на всички хукове `SessionEnd` заедно се отделя секунда и половина. Асинхронните изобщо не са ограничени.

В Windows е добре да помните за формата с отделен списък с аргументи: тя се изпълнява без шел и ѝ трябва истински изпълним файл – обвивките `.cmd` и `.bat` изискват или низова форма, или стартиране през интерпретатор.

### Git: комити, pull request, атрибуция

| Параметър | Тип | Какво прави |
|---|---|---|
| `attribution` | обект | Текст на атрибуцията в комитите и описанията; празен низ я скрива. Полето `sessionUrl` управлява връзката към сесията. |
| `includeCoAuthoredBy` | boolean | **[остар]** Добавя съавторство. По-добре използвайте `attribution`. |
| `includeGitInstructions` | boolean | Включва вградените инструкции за комити в системния промпт. По подразбиране – да. |
| `prUrlTemplate` | низ | Шаблон на връзката към pull request: `{host}`, `{owner}`, `{repo}`, `{number}`, `{url}`. |
| `doneMeansMerged` | boolean | **[експ]** „Готово значи слято“: агентът продължава, докато pull request не е готов за сливане. |

```json title=".claude/settings.json"
{
  "attribution": { "commit": "", "pr": "" },
  "includeGitInstructions": true
}
```

### Интерфейс и терминал

| Параметър | Тип | Какво прави |
|---|---|---|
| `theme` | вж. по-долу | Цветова тема. |
| `editorMode` | `normal`, `vim` | Режим на клавишите в полето за въвеждане. Замени премахнатата команда `/vim`. |
| `keybindingFlavor` | `classic`, `readline` | Как се държат клавишите за думи. `readline` – като в Bash: изтриване до интервал, преходи по думи, пунктуацията разделя думите. |
| `vimInsertModeRemaps` | обект | Собствени изходи от режима на вмъкване, например `{"jj": "<Esc>"}`. |
| `emojiCompletionEnabled` | boolean | Автодовършване на емоджи в полето за въвеждане. По подразбиране – включено. |
| `wheelScrollAccelerationEnabled` | boolean | Ускорение на превъртането с колелцето. Само в режим на цял екран. |
| `defaultView` | `chat`, `transcript` | От кой изглед се отваря сесията. |
| `axScreenReader` | boolean | Плосък изход за екранни четци. |
| `tui` | `default`, `fullscreen` | Рендерер на интерфейса. |
| `viewMode` | `default`, `verbose`, `focus` | Режим на преглед на транскрипта при старта. |
| `verbose` | boolean | Пълен изход на инструментите вместо съкратени обобщения. |
| `autoScrollEnabled` | boolean | Автоматично превъртане на диалога надолу. Само в режим на цял екран. |
| `syntaxHighlightingDisabled` | boolean | Изключва подсветката на синтаксиса в diff-овете. |
| `prefersReducedMotion` | boolean | Намалява или премахва анимациите. |
| `showTurnDuration` | boolean | Показва продължителността след всеки ход. |
| `showMessageTimestamps` | boolean | Поставя на съобщенията времето на пристигане. |
| `terminalProgressBarEnabled` | boolean | Изпраща прогреса на дългите операции с управляващи последователности на терминала. |
| `terminalTitleFromRename` | boolean | Нека `/rename` променя заглавието на раздела. По подразбиране – да. |
| `spinnerTipsEnabled` | boolean | Показва подсказки в спинъра за изчакване. |
| `spinnerVerbs` | обект | Собствени глаголи на спинъра: добавяне към стандартните или замяна. |
| `spinnerTipsOverride` | обект | Собствени подсказки: със списък, с файл или със собствено заглавие вместо „Tip“. |
| `footerLinksRegexes` | масив от обекти | Собствени значки-връзки във футъра по регулярен израз. Най-много пет. |
| `spellcheck` | обект | Подчертава правописните грешки в полето за въвеждане. Нужен е инсталиран проверител: `aspell`, `hunspell` или `ispell`. |
| `companyAnnouncements` | масив от низове | Обяви при старта; ако са няколко, показва се случайна. |
| `todoFeatureEnabled` | boolean | Включва панела за проследяване на задачи. |

Стойности на `theme`: `auto` (по фона на терминала), `dark`, `light`, `light-daltonized`, `dark-daltonized`, `light-ansi`, `dark-ansi`, а също `custom:<име>` за тема от `~/.claude/themes/` и `custom:<плъгин>:<име>` за тема от плъгин.

Част от ключовете се четат само от потребителския файл, `--settings` и политиката: `spinnerTipsOverride` с файл с подсказки, `footerLinksRegexes` и `spellcheck`. Проектният файл не може да ги припокрие – иначе хранилището би могло да ви дорисува в интерфейса произволна връзка.

### Настройки, които живеят в `~/.claude.json`

Тези ключове в `settings.json` се игнорират тихо. Обикновено ги пише самият Claude Code или `/config`, но е полезно да знаете за тях.

| Параметър | Тип | Какво прави |
|---|---|---|
| `permissionExplainerEnabled` | boolean | **[глобален]** Ctrl+E върху диалога за разрешение показва разбор на командата: какво прави, защо и какво може да се обърка, с оценка на риска. По подразбиране – включено. |
| `diffTool` | `auto`, `terminal` | **[глобален]** Къде да се показва diff-ът на промяната, ако е свързана IDE. По подразбиране – в IDE. |
| `autoConnectIde` | boolean | **[глобален]** Свързва се автоматично с работеща IDE при стартиране от външен терминал. По подразбиране – не. |
| `autoInstallIdeExtension` | boolean | **[глобален]** Инсталира разширението автоматично при стартиране от терминала на VS Code. По подразбиране – да. |
| `externalEditorContext` | boolean | **[глобален]** При редактиране на промпта във външен редактор с Ctrl+G показва предишния отговор като коментари в началото на буфера. |
| `skippedMarketplaces` | масив от низове | **[глобален]** Маркетплейси, чиято инсталация сте отхвърлили. |
| `skippedPlugins` | масив от низове | **[глобален]** Плъгини, чиято инсталация сте отхвърлили. |

Първият ключ си струва да се научи: комбинацията Ctrl+E върху въпроса за стартиране на команда дава човешки разбор на това какво прави тази команда – без да се изпълнява. При непозната команда от чуждо хранилище това е точно бутонът, който липсва.

### Ред на състоянието

| Параметър | Тип | Какво прави |
|---|---|---|
| `statusLine` | обект | Собствен ред на състоянието долу, който се рисува от външен скрипт. |
| `subagentStatusLine` | обект | Ред на състоянието за всеки субагент в панела на агентите. |

Полета на `statusLine`: `type` със стойност `"command"`, `command` със скрипта, `padding`, `refreshInterval` – преизчислява на всеки толкова секунди, – и `hideVimModeIndicator`, ако скриптът рисува режима на vim сам.

```json title=".claude/settings.json"
{
  "statusLine": {
    "type": "command",
    "command": "~/.claude/statusline.sh",
    "padding": 1,
    "refreshInterval": 5
  }
}
```

Скриптът получава на входа JSON с контекста на сесията: модел, папка, цена, запълненост на контекста. Той печата един ред. Това е може би най-подценената настройка: постоянно видимите цифри за разхода променят поведението по-силно от всякакви инструкции за икономия. Имайте предвид само, че `disableAllHooks` изключва и нея.

### Контекст, памет, сесии

| Параметър | Тип | Какво прави |
|---|---|---|
| `cleanupPeriodDays` | число от 1 | Колко дни да се пазят транскриптите. По подразбиране трийсет. Заедно с това определя срока на живот на контролните точки. |
| `desktopSessionCleanupPeriodDays` | число от 0 | Таван за изключението, по което сесиите на desktop приложението надживяват обикновеното почистване. |
| `crossSessionInbound` | `accept`, `hold`, `refuse` | Какво да се прави със съобщенията от други ваши сесии. |
| `dialogExpiry` | `60s`, `5m`, `10m`, `never` | След колко време изтича диалог без отговор. По подразбиране пет минути. |
| `askUserQuestionTimeout` | същите стойности | Същото за въпросите на агента към вас. По подразбиране не изтичат. |
| `autoContinueAtUsageLimit` | boolean | Продължава сесията, когато лимитът на плана се нулира. **По подразбиране – включено.** |
| `autoMemoryEnabled` | boolean | Автоматична памет на проекта. |
| `autoMemoryDirectory` | низ, път | Папка на хранилището на автопаметта. Чете се от всяко ниво на настройките. |
| `autoDreamEnabled` | boolean | Фонова консолидация на паметта. |
| `fileCheckpointingEnabled` | boolean | Прави копия на файловете преди промени, за да може `/rewind` да ги възстанови. |
| `outputStyle` | низ | Стил на отговорите на асистента. |
| `language` | низ | Предпочитан език на отговорите и на гласовото въвеждане, например `"russian"`. |
| `promptSuggestionEnabled` | boolean | Показва подсказки за промпти. |
| `awaySummaryEnabled` | boolean | **[експ]** Резюме на сесията при връщане след отсъствие, по-дълго от пет минути. |
| `showClearContextOnPlanAccept` | boolean | Предлага изчистване на контекста при приемане на план. По подразбиране – не. |
| `plansDirectory` | низ, път | Папка за файловете с планове спрямо корена на проекта. |
| `claudeMd` | низ | **[админ]** Инструкции в стила на `CLAUDE.md` като организационна памет. |
| `claudeMdExcludes` | масив от шаблони | Кои файлове `CLAUDE.md` да не се зареждат. Файлът на политиката не може да се изключи. |
| `respectGitignore` | boolean | Файловият избирач отчита `.gitignore`. По подразбиране – да; `.ignore` се отчита винаги. |
| `fileSuggestion` | обект | Собствен източник на подсказки за файлове за споменавания през `@`. |

За `autoContinueAtUsageLimit` си струва да знаете две неща: включен е по подразбиране и се чете само от потребителския файл, `--settings` и политиката – тоест проектен или локален файл, който го задава, не се игнорира, а **изключва** възможността.

### Скилове

| Параметър | Тип | Какво прави |
|---|---|---|
| `skillOverrides` | обект | Видимост на скила: `on`, `name-only` – само името без описание, `user-invocable-only` – скрива го от модела, но оставя извикването по име, `off` – скрива го напълно. |
| `skillListingMaxDescChars` | число | Лимит на знаците за описание на скил в листинга. По подразбиране 1536. |
| `skillListingBudgetFraction` | число 0–1 | Дял от контекста за целия листинг на скиловете. По подразбиране един процент. |
| `disableSkillShellExecution` | boolean | Забранява вградените извиквания на шела в скиловете и в собствените команди. |
| `disableBundledSkills` | boolean | Не зарежда вградените скилове. Изключение – `/doctor`. |
| `syncClaudeAiSkills` | boolean | Дали да се теглят скиловете, синхронизирани с claude.ai. Отчита се само стойността `false`. |
| `syncClaudeAiPlugins` | boolean | Същото за плъгините. |

`skillOverrides` си струва да го знае всеки, който има много скилове: описанията им висят в контекста постоянно, и `name-only` за рядко нужните освобождава забележимо парче. Същият ключ е начин да забраните на агента сам да стартира конкретна команда, оставяйки я на вас: стойността `user-invocable-only`.

### Плъгини и маркетплейси

| Параметър | Тип | Какво прави |
|---|---|---|
| `enabledPlugins` | обект | Кои плъгини са включени; ключът е `плъгин@маркетплейс`. |
| `pluginConfigs` | обект | Конфигурация на всеки плъгин. **В проектните настройки се игнорира.** |
| `extraKnownMarketplaces` | обект | Допълнителни маркетплейси за това хранилище. |
| `strictKnownMarketplaces` | масив от източници | **[админ]** Само тези източници могат да се добавят. Поддържа `owner/*` – цялата организация. |
| `blockedMarketplaces` | масив от източници | **[админ]** Блокирани източници. |
| `pluginSuggestionMarketplaces` | масив от низове | **[админ]** Чиито плъгини могат да попадат в подсказките за инсталация. |
| `strictPluginOnlyCustomization` | boolean или масив | **[админ]** Забранява кастомизацията извън плъгините за `skills`, `agents`, `hooks`, `mcp`. |
| `pluginTrustMessage` | низ | **[админ]** Допълнителен текст към предупреждението преди инсталация. |
| `disableCommandPluginSources` | boolean | **[админ]** Забранява маркетплейси от вида „локална команда печата пътя към плъгина“. |
| `disableSideloadFlags` | boolean | **[админ]** Забранява подхвърлянето на плъгини с флагове. |

### Workflow-и, агенти, тиймейти

| Параметър | Тип | Какво прави |
|---|---|---|
| `enableWorkflows` | boolean | Включва или изключва workflow-ите. |
| `disableWorkflows` | boolean | Изключва workflow-ите. |
| `workflowKeywordTriggerEnabled` | boolean | Думата „ultracode“ в промпта включва workflow-и за хода. По подразбиране – да. |
| `skipWorkflowUsageWarning` | boolean | **[експ]** Предупреждението за цената на мултиагентните workflow-и е прието. |
| `workflowSizeGuideline` | `unrestricted`, `small`, `medium`, `large` | Ориентир за размера на разклоненията (fan-out): под пет агента, под петнайсет, под петдесет или без подсказка. |
| `disableAgentView` | boolean | **[админ]** Изключва екрана на агентите, фоновото стартиране и фоновата услуга. |
| `disableAutoMode` | `"disable"` | Изключва авто режима. Само като низ. |
| `teammateMode` | `in-process`, `tmux`, `iterm2`, `auto` | Как се показват тиймейтите. По подразбиране `in-process`. |

Стойността `auto` на `teammateMode` е определена точно: разделени панели, ако сесията върви вътре в tmux, или вътре в iTerm2 с достъпна помощна програма за командния ред, или ако tmux е инсталиран; иначе всичко се изпълнява вътре в процеса. Стойността `iterm2` – родни разделени панели на iTerm2, появи се във версия 2.1.186.

Ключът `teammateDefaultModel` в схемата още го има, но **е премахнат от продукта във версия 2.1.234** и на нищо не влияе.

### Worktree

Вложеният обект `worktree` управлява как се създават отделни работни копия за сесиите и фоновите агенти.

| Поле | Тип | Какво прави |
|---|---|---|
| `symlinkDirectories` | масив от низове | Какво да се свърже със симлинк от основното хранилище, за да не се раздува дискът. По подразбиране – нищо. |
| `sparsePaths` | масив от низове | Кои пътища да се включат чрез разредено изтегляне. Силно ускорява в монорепозиторита. |
| `baseRef` | `fresh`, `head` | От какво се разклоняват новите копия: от отдалечения основен клон или от локалното състояние. |
| `bgIsolation` | `worktree`, `none` | Изолация на фоновите сесии. По подразбиране фоновият агент не променя основното дърво. |
| `location` | низ, път | Къде desktop приложението създава копия за сесиите по SSH. **CLI още не я чете.** |

```json title=".claude/settings.json"
{
  "worktree": {
    "symlinkDirectories": ["node_modules", ".cache"],
    "sparsePaths": ["packages/app", "packages/shared"],
    "baseRef": "fresh",
    "bgIsolation": "worktree"
  }
}
```

### Отдалечено управление, SSH, среди

| Параметър | Тип | Какво прави |
|---|---|---|
| `disableRemoteControl` | boolean | **[админ]** Изключва изцяло отдалеченото управление. |
| `remoteControlAtStartup` | boolean | Вдига моста за отдалечено управление във всяка сесия. |
| `isolatePeerMachines` | boolean | Изисква потвърждение, преди съобщението да отиде в сесия на друга машина. |
| `autoUploadSessions` | boolean | Огледално копира локалните сесии в уеб само за преглед. |
| `daemonColdStart` | `transient`, `ask` | Когато фонова услуга няма: да се вдигне за сесията или да се предложи да се инсталира постоянно. |
| `remote` | обект | Среда по подразбиране за отдалечените сесии. |
| `sshConfigs` | масив от обекти | **[админ]** Преднастроени SSH връзки: `id`, `name`, `sshHost`, `sshPort`, `sshIdentityFile`, `startDirectory`. |
| `sshHostAllowlist` | масив от шаблони | **[админ]** Ограничава SSH сесиите на приложението до тези хостове. `*` – всеки, `*.example.com` – домейнът и поддомейните. |
| `disableDesktopLocalSessions` | boolean | **[админ]** Забранява сесиите на самата машина в desktop приложението: работа само по SSH. |
| `browserExternalPageTools` | `"disabled"` | **[админ]** Забранява на агента да чете и пипа външни страници в браузъра на приложението. Локалните предварителни прегледи работят. |
| `disableBrowserExternalNavigation` | boolean | **[админ]** Забранява външната навигация в браузъра на приложението и на агента, и на човека. |
| `disableMobileSimulatorTools` | boolean | **[админ]** Отнема на агента инструментите на симулатора на iOS; на човека панелът му остава. |
| `requireCoworkFullVmSandbox` | boolean | **[админ]** Изпълнява инструментите в изолирана виртуална машина. |
| `channelsEnabled` | boolean | **[админ]** Разрешава канални известия. |
| `allowedChannelPlugins` | масив от обекти | **[админ]** Бял списък на каналните плъгини. |

Три от тези ключове приемат **само истинско булево `true`**: низът `"true"` или единицата ще бъдат игнорирани с предупреждение в журнала. Това са `disableDesktopLocalSessions`, `disableBrowserExternalNavigation` и `disableMobileSimulatorTools`. Терминалният CLI изобщо не ги чете – те са за desktop приложението.

За `requireCoworkFullVmSandbox` има важен страничен ефект: вътре в пълната виртуална машина **няма нито политика на устройството, нито файл с корпоративни настройки** – доставянето им там ще трябва да стане по друг начин.

```json title=".claude/settings.json"
{
  "remote": { "defaultEnvironmentId": "env-123" },
  "sshConfigs": [
    {
      "id": "prod-box",
      "name": "Prod",
      "sshHost": "deploy@prod.example.com",
      "sshPort": 22,
      "startDirectory": "~/app"
    }
  ]
}
```

### Известия, глас, почивки

| Параметър | Тип | Какво прави |
|---|---|---|
| `preferredNotifChannel` | `auto`, `iterm2`, `terminal_bell`, `iterm2_with_bell`, `kitty`, `ghostty`, `notifications_disabled` | По кой канал да се пращат системните известия. |
| `inputNeededNotifEnabled` | boolean | Пуш на телефона, когато чака потвърждение или въпрос. |
| `agentPushNotifEnabled` | boolean | Позволява на агента да праща проактивни мобилни пушове. |
| `voice` | обект | Гласово въвеждане: `enabled`, `mode` със стойност `hold` или `tap`, `autoSubmit`. |
| `voiceEnabled` | boolean | Диктовка при вход през claude.ai, ако политиката на организацията го позволява. **Не е същото като `voice.enabled`,** който я припокрива. |
| `breakReminder` | обект | **[експ]** Напомняне за почивка след дълга непрекъсната работа. Никога не блокира. |
| `quietHours` | обект | **[експ]** Тихи часове: един мек намек за сесия вътре в зададения прозорец на местно време. |

```json title=".claude/settings.json"
{
  "voice": { "enabled": true, "mode": "hold", "autoSubmit": true },
  "breakReminder": { "enabled": true, "intervalMinutes": 120 },
  "quietHours": { "enabled": true, "start": "22:00", "end": "07:00" }
}
```

### Пясъчник и мрежа

Обектът `sandbox` управлява какво е разрешено на процесите вътре в изолацията. Най-дългият раздел от схемата и най-рядко използваният – но ако пускате агента в режим, в който той не пита за разрешения, четете именно него.

Веднага ще поправя една разпространена грешка в структурата: пътищата за четене и запис стоят **не директно в `sandbox`, а в `sandbox.filesystem`.** Правилото `"sandbox": {"denyRead": [...]}` няма да сработи.

| Поле | Тип | Какво прави |
|---|---|---|
| `enabled` | boolean | Включва пясъчника. |
| `enabledPlatforms` | масив `macos`, `linux`, `wsl`, `windows` | **[админ]** Ограничава цялата конфигурация до тези системи. На останалите тя е изцяло инертна. |
| `autoAllowBashIfSandboxed` | boolean | Автоматично разрешава командите, ако се изпълняват в пясъчника. |
| `allowUnsandboxedCommands` | boolean | Позволява блокирана команда да се повтори извън пясъчника. **По подразбиране `true`.** |
| `failIfUnavailable` | boolean | Спира с грешка, ако пясъчникът не може да се вдигне, вместо тихо да стартира без него. |
| `excludedCommands` | масив от низове | Команди, изведени от пясъчника; задава ги `/sandbox exclude`. |
| `ignoreViolations` | обект | Кои нарушения да не се показват. |
| `filesystem.allowWrite` | масив от пътища | Допълнителни пътища, в които е разрешен записът. |
| `filesystem.denyWrite` | масив от пътища | Пътища, забранени за запис, в това число вътре в разрешена папка. |
| `filesystem.denyRead` | масив от пътища | Пътища, забранени за четене. |
| `filesystem.allowRead` | масив от пътища | Изключения, които отново разрешават четене вътре в забранени области. |
| `filesystem.allowManagedReadPathsOnly` | boolean | **[админ]** Пътищата за четене се вземат само от политиката. |
| `filesystem.disabled` | boolean | Изключва файловата част на пясъчника. Не от настройките на проекта. |
| `network.allowedDomains` | масив от низове | Разрешени домейни. |
| `network.deniedDomains` | масив от низове | Винаги блокирани домейни. |
| `network.allowManagedDomainsOnly` | boolean | **[админ]** Разрешават се само домейните от политиката. |
| `network.strictAllowlist` | boolean | Разрешават се само изрично изброените домейни. |
| `network.allowUnixSockets` | масив от низове | Разрешени Unix сокети. Само macOS. |
| `network.allowAllUnixSockets` | boolean | Разрешава всички Unix сокети. |
| `network.allowLocalBinding` | boolean | Разрешава локално свързване към портове. |
| `network.allowMachLookup` | масив от низове | Разрешени услуги на Mach. Само macOS, звездичката е допустима само в края. |
| `network.httpProxyPort` | число | Порт на вътрешния HTTP прокси на пясъчника. |
| `network.socksProxyPort` | число | Порт на вътрешния SOCKS прокси. |
| `network.tlsTerminate` | обект | **[експ]** Терминира TLS със собствен удостоверителен орган – нужно за маскиране на тайни. |
| `credentials.envVars` | масив от обекти | Какво да се прави с тайните в променливите: `deny` или `mask`, плюс извличане и разбор. |
| `credentials.files` | масив от обекти | Същото за файловете с тайни. |
| `credentials.awsPairs` | масив от обекти | Двойки AWS променливи, които пясъчникът подписва наново. |
| `credentials.sigv4` | обект | Какво да се прави с формите на заявки към AWS, които не могат да се подпишат наново: поточно качване, предварително подписан адрес и асиметричен подпис. Всяко поле е `deny` или `passthrough`; по подразбиране всичко е забранено. |
| `credentials.allowPlaintextInject` | boolean | Разрешава подмяна на тайни в открит текст. По подразбиране не. |
| `allowAppleEvents` | boolean | Разрешава Apple Events. Само macOS. |
| `enableWeakerNetworkIsolation` | boolean | **Отслабва защитата.** По-слаба мрежова изолация на macOS. |
| `enableWeakerNestedSandbox` | boolean | **Отслабва защитата.** Разрешава вложен пясъчник с по-слаба защита. |
| `bwrapPath` | низ, абсолютен път | **[админ]** Собствен бинарен файл на bubblewrap за Linux. |
| `socatPath` | низ, абсолютен път | **[админ]** Собствен бинарен файл на socat. |
| `ripgrep` | обект | Собствен ripgrep за пясъчника. Настройките на проекта не го заместват. |

Три неща си струва да се подчертаят.

**`allowUnsandboxedCommands` е включено по подразбиране.** Тоест команда, блокирана от пясъчника, агентът може да повтори отвън чрез специален параметър. Ако сте включили пясъчника заради изолацията, това най-вероятно не е това, което сте искали – изключва се с изрично `false`.

**`enabledPlatforms` прави конфигурацията изцяло инертна.** На система, която не е в списъка, няма да има нито пясъчник, нито автоматични разрешения, нито предупреждение при стартиране, нито спиране заради `failIfUnavailable`. Тихо, сякаш раздела го няма.

**Маскирането на тайни не работи навсякъде.** На macOS и Windows режимът `mask` се изражда в `deny`: няма с какво да се подмени стойността в движение. При записите за маскиране има още едно поле – `onExtractNoMatch`, което казва какво да се прави, ако регулярният израз не е намерил нищо: `warn` (по подразбиране) ще пропусне променливата немаскирана, `deny` ще я премахне вътре в пясъчника, `error` ще спре стартирането.

```json title=".claude/settings.json"
{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "allowUnsandboxedCommands": false,
    "network": {
      "allowedDomains": ["api.example.com", "*.githubusercontent.com"],
      "deniedDomains": ["telemetry.example.com"]
    },
    "filesystem": {
      "denyRead": ["~/.ssh", "~/.aws"],
      "denyWrite": ["~/.config"]
    }
  }
}
```

### Обновления и всичко останало

| Параметър | Тип | Какво прави |
|---|---|---|
| `autoUpdatesChannel` | `latest`, `stable`, `rc` | Канал за автоматични обновления. |
| `minimumVersion` | низ | Не позволява връщане под посочената версия при превключване на каналите. |
| `requiredMinimumVersion` | низ | **[админ]** Под тази версия организацията не позволява работа. |
| `requiredMaximumVersion` | низ | **[админ]** Таван на версията за организацията. |
| `managedSourcesBehavior` | `first-wins`, `merge` | **[админ]** Как се комбинират няколко източника на политика. |
| `wslInheritsWindowsSettings` | boolean | **[админ, Windows]** WSL чете политиката от пълната верига политики на Windows. |
| `processWrapper` | низ | **[админ]** С какво да се обвиват породените процеси. |
| `allowManagedPermissionRulesOnly` | boolean | **[админ]** Отчитат се само правилата за разрешения от политиката. |
| `defaultShell` | `bash`, `powershell` | Шел за командите, въведени чрез `!`. По подразбиране `bash` на всички платформи. |
| `respondToBashCommands` | boolean | Отговаря на командите, въведени чрез `!`. По подразбиране да. |
| `feedbackSurveyRate` | число 0–1 | Вероятност за показване на анкета за качеството на сесията. |
| `feedbackDrafts` | `notify`, `quiet`, `off` | Може ли агентът сам да подготвя чернова на отзив. Изпращате го пак вие. |
| `enableArtifact` | boolean | Публикуване на артефакти. Изключването във всеки слой има надмощие. |
| `disableArtifact` | boolean | **[остар]** Предшественик с обратен смисъл: `true` изключва, `false` се игнорира. |
| `disableClaudeAiConnectors` | boolean | Не зарежда облачните конектори. |
| `skipWebFetchPreflight` | boolean | Пропуска проверката на списъка със забранени адреси в строги корпоративни среди. |
| `$schema` | низ | Връзка към схемата на настройките: автодопълване и проверка в редактора. |

Схемата приема още няколко служебни ключа: `modelProposedGoals`, `totalTokensReminder` с роднините му и `disableDeepLinkRegistration`. Те са вътрешни, в интерфейса не се появяват и никъде не са описани.

## Променливи на средата

Блокът `env` в настройките е обект „име → стойност“. **Всички стойности са низове**: числата и флаговете се пишат в кавички, `"PORT": "3000"`, флагът е `"1"`.

Честна уговорка за пълнотата: официалната документация изброява поименно **триста четиридесет и девет** променливи, включително по региони за всеки модел при всеки доставчик и целия набор за телеметрия. Да ги преразказвам тук е безсмислено. По-долу са тези, които наистина се използват, плюс поведението на блока `env`, което никъде не е събрано на едно място.

```json title=".claude/settings.json"
{
  "env": {
    "CLAUDE_CODE_USE_POWERSHELL_TOOL": "1",
    "ANTHROPIC_MODEL": "claude-opus-5",
    "BASH_DEFAULT_TIMEOUT_MS": "120000",
    "DISABLE_TELEMETRY": "1"
  }
}
```

### Как се държи блокът `env`

**Той има предимство пред експорта от шела.** Стойността от файла с настройки се записва в средата на процеса върху наследената. Това е точно обратното на това, което обикновено се очаква.

**Променлива не може да се изтрие** – може да се зададе празен низ. При избора на доставчик празната стойност се счита за незададена, но дъщерните процеси ще получат именно празен низ.

**Стойностите се прочитат наново в движение**, когато файлът се промени – освен подсистемите, които се настройват само при стартиране, като телеметрията. А `/cd` от версия 2.1.246 налага `env` на новата папка върху този на старата.

**На настройките на проекта и на локалните не е разрешено всичко.** Отхвърлят се три групи: променливи, задаващи местоположението на файлове (`CLAUDE_CONFIG_DIR`, `CLAUDE_CODE_TMPDIR`, `HOME`, `TMPDIR`, `TMP`, `TEMP`, `XDG_*`); променливи, включващи изнасяне на съдържанието на сесията (`OTEL_LOG_RAW_API_BODIES`, `ENABLE_BETA_TRACING_DETAILED`, `BETA_TRACING_ENDPOINT`); и променливи, влияещи на стартирането и синхронизацията (`CLAUDE_CODE_PROCESS_WRAPPER`, `CLAUDE_CODE_SYNC_SKILLS`, `CLAUDE_CODE_SYNC_PLUGINS`, кешът и seed папката на плъгините). Списъкът се разшири именно в 2.1.251. Предупреждението за това се вижда само при дебъгване.

Още няколко променливи се игнорират във **всеки** файл и се четат само от средата при стартиране: `CLAUDE_CODE_REMOTE`, `CLAUDE_CODE_ACCOUNT_UUID`, сокетът и токенът за обмен между сесиите, `CLAUDE_CODE_PROJECT_DIR_NAME` и `CLAUDE_CODE_RESTRICTED`.

**И обратната посока, за която почти не се пише: Claude Code сам задава променливи на дъщерните процеси.** Виждат се от хуковете и от всеки стартиран скрипт: `CLAUDECODE=1`, `CLAUDE_CODE_CHILD_SESSION=1`, `CLAUDE_CODE_SESSION_ID`, `CLAUDE_PID` – собственият идентификатор на процеса, `CLAUDE_EFFORT` с текущото ниво на усилие (режимът `ultracode` се показва като `xhigh`), а в облачните сесии `CLAUDE_CODE_REMOTE=true` и идентификатор на отдалечената сесия. Хук, на който трябва да знае нивото на усилие или да различи дъщерна сесия от основната, го взема оттук, а не гадае.

### Доставчици и автентикация

| Променлива | Какво прави |
|---|---|
| `ANTHROPIC_API_KEY`, `ANTHROPIC_AUTH_TOKEN` | Ключ и токен на Anthropic API. |
| `CLAUDE_CODE_OAUTH_TOKEN` | Токен на абонамента – вход без интерактивен логин. |
| `ANTHROPIC_BASE_URL` | Собствен базов адрес на API: прокси или шлюз. |
| `ANTHROPIC_CUSTOM_HEADERS` | Допълнителни HTTP хедъри към API. |
| `ANTHROPIC_BETAS` | Beta хедъри в заявките. |
| `CLAUDE_CODE_USE_BEDROCK`, `CLAUDE_CODE_USE_VERTEX` | Включват Amazon Bedrock или Google Cloud като доставчик. |
| `ANTHROPIC_BEDROCK_REGION_PREFIX` | Кой междурегионален профил да се предпочете пред изведения от региона на AWS. |
| `ANTHROPIC_BEDROCK_BASE_URL`, `ANTHROPIC_VERTEX_BASE_URL` | Собствени адреси на доставчиците. |
| `AWS_BEARER_TOKEN_BEDROCK`, `ANTHROPIC_VERTEX_PROJECT_ID` | Данните за достъп до Bedrock и проектът в Google Cloud. |
| `CLAUDE_CODE_SKIP_BEDROCK_AUTH`, `CLAUDE_CODE_SKIP_VERTEX_AUTH` | Пропускат оторизацията при доставчика, когато я върши шлюзът. |
| `HTTPS_PROXY`, `HTTP_PROXY`, `NO_PROXY` | Прокси за изходящия трафик. |
| `NODE_EXTRA_CA_CERTS` | Собствен коренов сертификат за корпоративен прокси. |

Доставчиците, между другото, не са два или три: освен Anthropic API, Amazon Bedrock и Google Cloud се поддържат Microsoft Foundry и Claude Platform на AWS, като всеки има собствен набор от променливи и собствено съответствие на алиасите на моделите.

### Модели, контекст, лимити

| Променлива | Какво прави |
|---|---|
| `ANTHROPIC_MODEL` | Основният модел. Има предимство пред ключа `model` от файловете. |
| `ANTHROPIC_DEFAULT_MODEL` | Модел за новите сесии; действа само ако `model` не е зададен никъде. |
| `ANTHROPIC_DEFAULT_OPUS_MODEL` и такива за sonnet, haiku и fable | Какво стои зад алиасите. |
| `ANTHROPIC_SMALL_FAST_MODEL` | **[остар]** Малък бърз модел. Заменена с `ANTHROPIC_DEFAULT_HAIKU_MODEL`. |
| `CLAUDE_CODE_SUBAGENT_MODEL` | Модел за субагентите. |
| `CLAUDE_CODE_EFFORT_LEVEL` | Ниво на усилие. **Има предимство пред `--effort` и `/effort`.** |
| `MAX_THINKING_TOKENS` | Лимит на токените за разсъждения. |
| `CLAUDE_CODE_MAX_OUTPUT_TOKENS`, `MAX_MCP_OUTPUT_TOKENS` | Лимит на изходните токени и на изхода на MCP. |
| `CLAUDE_CODE_DISABLE_1M_CONTEXT` | Не използва прозореца от един милион токена. |
| `CLAUDE_CODE_MAX_CONTEXT_TOKENS` | Собствен таван на контекстния прозорец. |
| `CLAUDE_CODE_AUTO_COMPACT_WINDOW`, `CLAUDE_AUTOCOMPACT_PCT_OVERRIDE` | Прозорец за автоматично свиване в токени и в проценти. |
| `DISABLE_AUTO_COMPACT` | Изключва автоматичното свиване. |
| `DISABLE_PROMPT_CACHING` | Изключва кеширането на промпта. |
| `API_TIMEOUT_MS`, `CLAUDE_CODE_MAX_RETRIES` | Таймаут на заявката към API и брой повторения. |

### Поведение и среда

| Променлива | Какво прави |
|---|---|
| `CLAUDE_CONFIG_DIR` | Друга папка за цялата конфигурация. |
| `CLAUDE_CODE_PROJECT_DIR_NAME` | Кратко име на папката с транскрипти и автопаметта на проекта. **Задава се само заедно с `CLAUDE_CONFIG_DIR`** и само от средата при стартиране. |
| `CLAUDE_CODE_TMPDIR` | Директория за временни файлове. |
| `CLAUDE_CODE_USE_POWERSHELL_TOOL` | Използва инструмента PowerShell вместо bash. |
| `CLAUDE_CODE_GIT_BASH_PATH` | Път до Git Bash на Windows. |
| `CLAUDE_CODE_SHELL`, `CLAUDE_CODE_SHELL_PREFIX` | Шел и префикс към командите на шела. |
| `CLAUDE_ENV_FILE` | Скрипт, изпълняван преди всяка команда на шела **в същия процес** – така оцеляват извикванията за активиране на виртуална среда. |
| `CLAUDE_BASH_MAINTAIN_PROJECT_WORKING_DIR` | Връща се в изходната папка след всяка команда: `cd` вътре в извикването не се запазва. |
| `BASH_DEFAULT_TIMEOUT_MS`, `BASH_MAX_TIMEOUT_MS` | Таймаут на командите по подразбиране и максимален. |
| `BASH_MAX_OUTPUT_LENGTH` | Лимит на дължината на изхода на команда. |
| `CLAUDE_CODE_TOOL_MEMORY_LIMIT` | Лимит на паметта за командите чрез контролни групи. Само Linux. |
| `MCP_TIMEOUT`, `MCP_TOOL_TIMEOUT` | Таймаут на стартиране на сървъра и на извикване на инструмент. |
| `CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS` | Колко субагента работят едновременно. По подразбиране двадесет. |
| `CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH` | Дълбочина на вложеност на субагентите. По подразбиране три; единица изключва вложеността. |
| `CLAUDE_CODE_MAX_TOOL_USE_CONCURRENCY` | Колко паралелни извиквания само за четене. По подразбиране десет. |
| `TASK_MAX_OUTPUT_LENGTH` | Таван на изхода на субагент в символи: по подразбиране 32000, максимум 160000. |
| `CLAUDE_CODE_ENABLE_TASKS` | Кои инструменти за задачи да се дават: по подразбиране новите, нулата връща стария единен инструмент. |
| `CLAUDE_CODE_ENABLE_TODO_TOOLS` | Връща инструментите за задачи на моделите, на които са били махнати. |
| `USE_BUILTIN_RIPGREP` | Използва вградения ripgrep. |
| `CLAUDE_CODE_WEBFETCH_CACHE_TTL_MS` | Колко да се държат в кеша заредените страници. По подразбиране петнадесет минути. |
| `CLAUDE_CODE_DISABLE_BACKGROUND_TASKS` | Изключва фоновите задачи. |
| `CLAUDE_CODE_DISABLE_CLAUDE_MDS` | Не зарежда файловете `CLAUDE.md`. |
| `CLAUDE_CODE_SAFE_MODE`, `CLAUDE_CODE_RESTRICTED`, `CLAUDE_CODE_SIMPLE` | Същото като едноименните флагове за стартиране. |

Три капана в тази таблица заслужават да се изговорят.

**Таймаутите на MCP се различават с повече от три порядъка.** Стартирането на сървър е тридесет секунди. А извикването на инструмент по подразбиране е около двадесет и осем часа, тоест на практика без ограничение. Освен това при сървърите по HTTP и при облачните конектори **всяка заявка** е допълнително ограничена до една минута и това е отделен лимит.

**`CLAUDE_CODE_PROJECT_DIR_NAME` сама не работи** – само заедно с `CLAUDE_CONFIG_DIR` и само от средата, а не от файла с настройки.

**Безопасният режим отнема повече, отколкото изглежда.** `CLAUDE_CODE_SAFE_MODE` не е само инструкции и скилове: не се зареждат плъгини, хукове, MCP сървъри, собствени команди и агенти, стилове на изхода, работни процеси, теми, бързи клавиши, статус лентата, източникът на подсказки за файлове, езиковите сървъри и автопаметта. Остава само корпоративната политика, включително зададените от нея хукове и статус лента. Това е режим за дебъгване „изключи всичко, което съм настроил“ и за търсене на счупена конфигурация е идеален.

### Рендериране и достъпност

С един ред, защото променливите са много, а са нужни рядко. Класическият рендерер се връща с `CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN` и той е **по-силен** и от `CLAUDE_CODE_NO_FLICKER`, и от настройката `tui`. Има отделни превключватели за мишката и кликовете, скоростта на превъртане, виртуалното превъртане, пълното пререндериране, родния курсор, оцветяването на синтаксиса, хипервръзките и truecolor в tmux. За достъпност – `CLAUDE_AX_SCREEN_READER` и сродните ѝ.

### Поверителност, телеметрия, обновления

| Променлива | Какво прави |
|---|---|
| `CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC` | Един превключвател за целия незадължителен изходящ трафик. |
| `DISABLE_TELEMETRY`, `CLAUDE_CODE_ENABLE_TELEMETRY` | Изключват и включват телеметрията. |
| `DO_NOT_TRACK` | Общоприета променлива със същия смисъл. |
| `DISABLE_GROWTHBOOK` | Не дърпа сървърните флагове на функциите. |
| `DISABLE_ERROR_REPORTING` | Не изпраща отчети за грешки. |
| `DISABLE_AUTOUPDATER`, `DISABLE_UPDATES` | Изключват автоматичните обновления. |
| `DISABLE_COST_WARNINGS` | Скрива предупрежденията за цена. |
| `DISABLE_FEEDBACK_COMMAND` | Скрива изпращането на отзиви. Старото име `DISABLE_BUG_COMMAND` също се приема. |
| `DISABLE_DOCTOR_COMMAND` | Скрива `/doctor`. |
| Семейството `OTEL_*` | Експорт на метрики, логове и трейсове. |

Три неща, на които тук се хващат хората.

**`DISABLE_BUG_COMMAND` не е отделен превключвател.** Това е старото име на `DISABLE_FEEDBACK_COMMAND` и една променлива изключва и `/feedback`, и черновите на отзиви, и `/bug` със `/share`, защото те тръгват по същия канал.

**Стойността `0` не включва обратно.** При `CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC` всяко наличие на променливата, включително `0` и `false`, изключва трафика. За да го върнете, променливата трябва да се махне изцяло.

**Изключването на телеметрията изключва и функции.** Заедно с флаговете на функциите спират да работят: авторежимът по подразбиране, `/auto-mode-setup`, отдалеченото управление, `/import`, `/schedule`, съветникът, коментарите към артефакти, новият MCP клиент и инструментът PowerShell по подразбиране на Windows. Това е осъзнат компромис, а не страничен дефект, но е хубаво да го знаете, преди да търсите половин час къде е изчезнало отдалеченото управление.

Какво точно покрива „целият незадължителен трафик“: автоматичните обновления, телеметрията, отчетите за грешки, изпращането на отзиви, бележките за изданието, обновяването на списъка с модели при шлюза и проверките за достъпност. Плюс – което е неочаквано – фоновото стартиране на локалните команди – източници на плъгини, защото те могат да повлекат инсталиране на зависимости. А автоматичното инсталиране на официалния маркетплейс не го покрива, за него има своя променлива.

## Терминални команди и флагове

Всичко, което се въвежда не вътре в сесията, а в обикновения шел. За всяка подкоманда по-долу е събрано всичко наведнъж: нейните собствени подкоманди и флагове, тънкости и примери.

Веднага най-важното, и това е официална формулировка, а не мое наблюдение: **`claude --help` не изброява всички флагове.** Липсата на флаг в справката не значи, че го няма. По-долу е отбелязано кои липсват в справката – такива са поне дузина и сред тях има напълно работещи неща като ограничаването на броя ходове.

Ако сгрешите името на подкоманда, ще ви предложат най-близката и ще излязат, без да стартират сесия: на `claude udpate` ще получите въпрос дали не сте имали предвид `claude update`.

### Подкоманди

#### `claude [промпт]`

Стартира интерактивна сесия в текущата папка – обичайният начин да започнете работа. Промптът като аргумент не променя режима: сесията си остава интерактивна, просто първият ход се прави веднага, без да се чака въвеждане. Удобно е, когато задачата вече е формулирана и не искате да я печатате отделно. Не го бъркайте с `-p`: там отговорът се отпечатва веднъж и процесът завършва.

Отваря се един и същ стартов екран: версия, акаунт и модел, текуща папка, подсказки и скорошна активност. С промпт като аргумент той също се показва, но никой не чака въвеждане – първият ход започва веднага.

```bash
claude                                    # интерактивна сесия

# така стартовият екран изглежда в отчет на потребител, билд 2.0.26
╭─── Claude Code v2.0.26 ─────────────────────────────────────────────────────╮
│                                       │ Tips for getting started            │
│          Welcome back ksmith!         │ Ask Claude to create a new appor c… │
│                                       │                                     │
│───────────────────────────────────────│                                     │
│                ▐▛███▜▌                │ Recent activity                     │
│               ▝▜█████▛▘               │ No recent activity                  │
│                 ▘▘ ▝▝                 │                                     │
│                                       │                                     │
│        Sonnet 4.5 · Claude Max        │                                     │
│   /Users/ksmith/claude-context-test   │                                     │
╰─────────────────────────────────────────────────────────────────────────────╯

claude "поправи падащия тест в orders"    # сесия, веднага със задача
```

#### `claude -p "<промпт>"`

Неинтерактивно стартиране: Claude Code изпълнява един промпт, отпечатва резултата в стандартния изход и завършва. Това е основният режим за скриптове, конвейери и CI – изходът може да се предаде нататък или да се запази във файл. Сесията при това е пълноценна: инструментите, правата и настройките на проекта действат същите, просто няма кого да попита. Оттук идва и една тънкост: ако е избран модел или режим, които харчат кредити, няма да ви покажат еднократно съгласие за харченето – интерактивната сесия пита, а `-p` и Agent SDK харчат мълчаливо.

На екрана се появява само самият отговор: нито стартов екран, нито поле за въвеждане в този режим няма.

```bash
claude -p "какво прави този скрипт?"      # отговаря и излиза
```

#### `claude auth login|logout|status`

Вход, изход и статус на автентикацията. Статусът се отпечатва като JSON – с това е удобно в скрипт да проверите дали машината изобщо е влязла в акаунт, преди да стартирате нещо на нея. Част от възможностите са вързани не към ключ за API, а именно към вход в акаунт на claude.ai, затова търсенето на причината за неясно „функцията не е налична“ е разумно да започне оттук.

Входът предлага да изберете с какво да плащате: абонамент към claude.ai или таксуване през Console. Флагът `--console` избира второто веднага, без въпрос. След това се отваря браузър и чака потвърждение; `logout` изтрива запазените данни за достъп от машината.

```bash
claude auth login --console               # вход през таксуване в Console

claude auth status                        # статус на автентикацията в JSON

claude auth logout                        # изход
```

#### `claude setup-token`

Издава дългоживеещ токен за автентикация. **[не във всички планове]** Нужен е абонамент. Токенът е нужен там, където не може да се влезе интерактивно – билд сървър, контейнер, CI: слага се в променлива на средата и `claude -p` работи без браузър и без човек.

Входът се потвърждава в браузъра, след което токенът се отпечатва в терминала – оттам го пренасят в средата на билд машината.

```bash
claude setup-token                        # дългоживеещ токен за CI
```

#### `claude agents`

Екран за управление на фоновите агенти; той е и техният стартер. Фонов агент е сесия, която живее отделно от вашия терминал: поставяте задача, затваряте прозореца и се връщате за резултата. На този екран се вижда какво е стартирано, какво е приключило и какво е паднало; всичко това е достъпно и като отделни подкоманди (`attach`, `logs`, `stop`, `rm`), екранът просто ги събира на едно място.

Избирате от списъка нужната сесия, а после – какво да правите с нея: да я отворите в своя терминал, да видите изхода ѝ, да я спрете или да я изтриете заедно с работното копие. Имайте предвид, че всяка фонова сесия харчи лимита на плана като обикновена: петима агенти, работещи едновременно, го изяждат пет пъти по-бързо.

```bash
claude agents                             # екран на фоновите агенти

# така този списък изглежда в документацията
Pinned
  ✽ clawd walk cycle          Drawing the walk-cycle sprite frames          3m

Ready for review
  ∙ jump physics              Opened PR with collision fix                 #2048  2h

Needs input
  ✻ power-up design           double jump or wall climb?                    1m

Working
  ✽ collision detection       Adding swept-AABB checks to CollisionSystem   2m
  ✢ playtest level 3          run 12 · all checkpoints cleared           in 4m

Completed
  ✻ title screen              result: menu, options, and credits done       9m
  ∙ sound effects             result: 14 SFX exported to assets/audio       4h
  … 6 more
```

#### `claude attach <id>`

Отваря фонова сесия в този терминал. Получавате целия ѝ разговор и продължавате работа, сякаш сте я стартирали тук. Нужно е, когато агентът е заседнал на въпрос или е тръгнал накриво и по-нататък е по-лесно да го водите на ръка. Идентификаторът се взема от `claude agents` или от изхода при стартиране.

```bash
claude attach a1b2c3                      # свързване към фонова сесия
```

#### `claude logs <id>`

Отпечатва последния изход на фонова сесия и излиза. Бърз начин да разберете с какво е зает агентът, без да го взимате при себе си и без да му пречите да работи. Удобно е да се вика от скрипт, когато трябва да се дочака резултат или просто да се провери, че работата върви.

```bash
claude logs a1b2c3                        # последният изход на фоновата сесия
```

#### `claude stop <id>`

Спира фонова сесия; разговорът се запазва. Псевдоним: `kill`. Това не е изтриване: сесията спира да работи и да харчи лимит, но изходът ѝ и работното ѝ копие остават на мястото си и могат да се разгледат. Ако сесията е нужна не спряна, а напълно премахната – това е `claude rm`.

```bash
claude stop a1b2c3                        # спиране
```

#### `claude respawn [id]`

Рестартира фонова сесия или всички на текущата версия. Смисълът е, че вече стартираните агенти продължават да работят на версията, с която са тръгнали, и обновяването на Claude Code не стига до тях само. Отделна сесия се рестартира по идентификатор, `--all` – всички наведнъж.

```bash
claude respawn --all                      # рестартира всички на новата версия
```

#### `claude rm <id>`

Изтрива фонова сесия и нейното работно копие. За разлика от `stop`, това е необратимо: изчезват и разговорът, и отделната папка, в която е работил агентът, заедно с всичко, което не сте взели от нея в клон. Полезно е да чистите приключилите сесии – иначе списъкът се запълва, а работните копия заемат място.

Ако в работното копие са останали комити, които ги няма никъде другаде, командата ще откаже да го пипне и ще каже, че е оставила всичко както е.

```bash
claude rm a1b2c3                          # изтрива сесията и нейното работно копие
```

#### `claude daemon`

Фонова услуга, която държи всички фонови сесии. Подкоманда, за която малцина знаят, макар да работи при всички: това е супервайзърът, който вдига и държи фоновите сесии. Сама по себе си не ви трябва точно до момента, в който агентът е спрял да отговаря или списъкът със сесии изглежда подозрително празен – тогава тук се идва за състоянието и журнала.

| Подкоманда | Какво прави |
|---|---|
| `status` | Състояние на услугата: версия, папка със сокетите, брой работни процеси |
| `run [път]` | Стартира услугата ръчно |
| `logs` | Журнал на услугата |
| `stop` | Спира; `--any` – заедно със сесиите, `--keep-workers` – като оставя работните процеси |
| `uninstall` | Премахва услугата |

Флаговете `--json-path` и `--log-file` променят местоположението на файла със състоянието и на журнала; по подразбиране това са `~/.claude/daemon.json` и `~/.claude/daemon.log`. Във версия 2.1.251 постоянното инсталиране на услугата е изключено: тя се вдига при нужда и завършва, когато се изключи последният клиент.

Капан за скриптовете: `claude --dangerously-skip-permissions daemon status` работи, а **всеки друг глобален флаг пред думата `daemon` ще стартира интерактивна сесия** вместо подкомандата. Слагайте подкомандата първа.

```bash
claude daemon status                      # състояние на фоновата услуга

claude daemon stop --any --keep-workers   # спира услугата, като оставя работните процеси
```

#### `claude mcp`

Настройка на MCP сървъри без стартиране на сесия. MCP сървърът е това, с което моделът стига извън проекта: до тракера на задачи, базата, файловата система, вътрешното API. Всичко това се настройва и вътре в сесията, но от шела е по-удобно, когато сървърите се разгръщат със скрипт или трябва да се заведат по един и същи начин на няколко машини.

| Подкоманда | Какво прави |
|---|---|
| `add <име> <команда-или-адрес> [аргументи...]` | Добавя сървър. |
| `add-json <име> <json>` | Добавя сървър с един ред JSON. |
| `add-from-claude-desktop` | Импортира сървъри от Claude Desktop. Само macOS и WSL. |
| `list`, `get <име>` | Списък и подробности. |
| `login <име>`, `logout <име>` | Автентикация в сървъра или изчистване на запазените данни за достъп. |
| `remove <име>` | Премахва сървър. |
| `reset-project-choices` | Нулира решенията „одобрен или отхвърлен“ за проектните сървъри. |
| `serve` | Стартира самия Claude Code като MCP сървър. |

Най-важният флаг тук е `--scope` и пропускането му обяснява добра половина от въпросите „защо сървърът се вижда само при мен“ или „защо изведнъж се появи при всички“. Стойности: `local` (по подразбиране), `project` – в `.mcp.json`, който се комитва, и `user` – в потребителските настройки. Има го при `add`, `add-json`, `add-from-claude-desktop` и `remove`.

Транспортите са четири, а не три: `stdio`, `http`, `sse` и `ws`. Кратки форми: `-t` вместо `--transport`, `-H` вместо `--header`. За OAuth има `--client-id`, `--client-secret` (ще попита или ще го вземе от променлива на средата) и `--callback-port`; при `login` допълнително `--no-browser`.

Неодобрените сървъри от `.mcp.json` се показват в списъка като чакащи одобрение и не се свързват. Добавянето се потвърждава с ред за това къде точно е отишъл записът; `list` преди печат обхожда сървърите и проверява дали отговарят, а `serve` не завършва – процесът остава в работа и говори през стандартния вход и изход.

```bash
claude mcp add fs npx -- -y @modelcontextprotocol/server-filesystem ~/work   # в локалния обхват

claude mcp add --scope project github https://api.example.com/mcp -t http   # в .mcp.json на проекта

claude mcp add-json local-tools '{"command":"./tools","args":["--serve"]}'   # същото от готов JSON

claude mcp list                          # какво е свързано и в какво състояние

# снето на билд 2.1.252
Checking MCP server health…

claude.ai Google Drive: https://drivemcp.googleapis.com/mcp/v1 - ✔ Connected
serena: C:/Users/user/.local/bin/uvx.exe --python 3.13 --from git+... - ✔ Connected

claude mcp serve                         # предоставя самия Claude Code като MCP сървър
```

#### `claude plugin`

Плъгини и маркетплейси. Псевдоним: `plugins`. Плъгинът е набор от скилове, агенти, команди, хукове и MCP сървъри, доставян и обновяван като едно цяло от маркетплейс. Оттук те се инсталират, включват, изключват и се правят собствени. Работи без стартиране на сесия, затова един и същ набор за целия екип е удобно да се разгръща със скрипт.

| Подкоманда | Какво прави |
|---|---|
| `install <плъгин>` | Инсталира от маркетплейс. Псевдоним `i`. |
| `uninstall <плъгин>` | Премахва. Псевдоними `remove`, `rm`. |
| `enable`, `disable` | Включва или изключва инсталиран плъгин. |
| `list` | Списък на инсталираните. Псевдоним `ls`. |
| `details <име>` | Опис на компонентите и оценка колко контекст ще изяде плъгинът. |
| `update <плъгин>` | Обновява; прилага се след рестартиране. |
| `marketplace` | Управление на маркетплейсите. |
| `init <име>` | Създава заготовка на плъгин. Псевдоним `new`. |
| `validate <път>` | Проверява манифеста, а също скиловете, агентите и командите в папката. |
| `eval [цел]` | Изпълнява проверочни случаи срещу плъгина и показва оценките. |
| `tag [път]` | Създава git таг на изданието, като сверява манифеста със записа в маркетплейса. |
| `prune` | Премахва автоматично инсталираните зависимости, които вече не са нужни. Псевдоним `autoremove`. |

Почти всички подкоманди имат `-s, --scope` със стойности `user` (по подразбиране), `project` и `local`, а `update` има и `managed`. Освен това: `install` има `--config ключ=стойност` (може няколко) и `-y`; `uninstall` – `--keep-data`, `--prune`, `-y`; `disable` – `-a` за всички; `list` – `--json` и `--available`; `prune` – `--dry-run` и `-y`; `validate` – `--strict`, който превръща предупрежденията в грешки; `init` – `--description`, `--author`, `--author-email`, `-f` и `--with` със списък на компонентите: `skills`, `agents`, `hooks`, `mcp`, `lsp`, `output-style`, `channel`.

Полезно е да знаете, че `validate` работи и върху обикновена папка със скилове и агенти, без никакъв плъгин.

Обикновеният `list` печата инсталираните плъгини с версия, обхват и състояние – включен или изключен; с `--json` същото идва машинночетимо, за разбор в скрипт.

```bash
claude plugin install code-review@claude-plugins-official   # инсталира от маркетплейс

claude plugin list --json                # какво е инсталирано, машинночетимо

# снето на билд 2.1.252, без --json
Installed plugins:

  ❯ frontend-design@claude-plugins-official
    Version: unknown
    Scope: project
    Status: ✔ enabled

claude plugin details formatter          # колко контекст заема

claude plugin init my-tools --with skills,hooks   # заготовка на плъгин

claude plugin validate ./my-tools --strict        # проверява манифеста и съдържанието на папката
```

#### `claude auto-mode`

Конфигурация на класификатора на авторежима. Авторежимът решава какво да се изпълни без въпрос и къде да спре и да попита вас; решава го по набор от правила, а правилата идват от три места – стандартния набор, вашите настройки, настройките на проекта. Тези подкоманди показват кое от тях в момента действа и откъде е дошло, дават да прочетете цялото стандартно правило и да поискате от модела да разгледа вашите собствени. Тук си струва да се дойде, когато авторежимът пита твърде често или, обратно, пропуска това, което не бива да пропуска.

| Подкоманда | Какво прави |
|---|---|
| `config` | Какво действа и откъде |
| `defaults` | Стандартните правила; с `--label` – пълният текст на едно правило |
| `critique` | Разбор на вашите правила от модела |
| `reset` | Нулиране; `--yes` – без потвърждение |

`defaults` печата JSON: обект с ключове `allow`, `soft_deny`, `hard_deny` и `environment`, във всеки – масив от дълги текстови правила със заглавия от вида „Security Discussion: …“. Флагът `--label` изрязва оттам едно правило изцяло.

```bash
claude auto-mode config                              # какво действа и откъде

claude auto-mode defaults --label 'Git Destructive'  # пълният текст на едно правило

claude auto-mode critique                            # разбор на вашите правила от модела

claude auto-mode reset --yes                         # нулиране без потвърждение
```

#### `claude project purge [път]`

Изтрива цялото състояние за проекта: транскрипти, задачи, история на файловете, записа в конфигурацията. Самият код не се пипа – премахва се само онова, което Claude Code е натрупал до него. Нужно е, когато проектът е закрит или когато в натрупаното състояние се е появило нещо, което не бива да е там. Преди истинското стартиране има смисъл да прегледате списъка чрез `--dry-run`.

```bash
claude project purge ~/work/my-repo --dry-run   # какво би било изтрито

# така изглежда в документацията
Purge plan for /home/user/work/my-repo:

  dir:    /home/user/.claude/projects/-home-user-work-my-repo
           project transcripts (.jsonl) and memory/
  config: projects["/home/user/work/my-repo"]
           project entry in ~/.claude.json (trust, history, MCP servers)
  filter: /home/user/.claude/history.jsonl
           12 prompt(s) typed in this project

shell-snapshots/ are not project-scoped and will not be touched
backups/ may still contain this project entry in old .claude.json snapshots (/home/user/.claude/backups); at most 5 are kept and they rotate out automatically
Dry run: 3 item(s) would be deleted.
```

#### `claude doctor`

Диагностика на инсталацията без стартиране на сесия и без промени. Прави набор от проверки за това как е инсталиран Claude Code и в какво състояние е средата му и отпечатва резултата ред по ред. Сама тя нищо не поправя: това е диагноза, а не лечение. С нея е разумно да започва всеки разбор на „защо не работи“, преди да променяте настройки наслуки.

```bash
claude doctor                             # диагностика без промени

# снето на билд 2.1.252
Claude Code doctor

Running: native (2.1.252)
Commit: c0778c45886d
Platform: win32-x64
Path: C:\Users\user\.local\bin\claude.exe
Config install method: native
Search: OK (bundled)
Auto-updates: enabled
Auto-update channel: latest
Last update attempt: success → 2.1.252 (2026-08-31)
Managed settings (remote): not fetched — requires an Enterprise or Team subscription

Remote Control
Control this session from claude.ai/code or the Claude mobile app

No installation issues found.

For a full setup checkup that can also fix issues, run /doctor in a Claude Code session.
```

#### `claude import [източник]`

Пренася конфигурация от друг агент за програмиране, за да не пренаписвате на ръка правила, команди и настройки, вече събрани за друг инструмент. Източникът се задава като аргумент. `--dry-run` показва какво точно би се пренесло, без нищо да променя – с него си струва да започнете, ако в текущата конфигурация вече има какво да се губи.

```bash
claude import codex --dry-run             # какво би се пренесло от друг агент
```

#### `claude install [версия]`

Инсталира нативния билд: `stable`, `latest` или конкретна версия. Нативният е отделен бинарен файл вместо пакет от npm и умее да се обновява сам. Аргументът избира какво точно да се инсталира: `stable` е провереният канал, `latest` – най-новият, а точен номер закрепя версията завинаги, както правят на билд машините, където поведението трябва да е еднакво днес и след месец.

```bash
claude install stable                     # инсталира стабилния билд
```

#### `claude update`

Проверява за обновления и ги инсталира. Псевдоним: `upgrade`. Нативният билд се обновява и сам, затова командата се вика на ръка, когато свежата версия трябва още сега – например заради възможност от конкретно издание. Вече стартираните фонови сесии обновлението няма да го вземат: след него те се рестартират чрез `claude respawn --all`.

Всичко започва с текущата версия и проверка на канала, а после – или инсталиране, или съобщение, че изтеглянето не е успяло.

```bash
claude update                             # обновява

# първите редове на истинския изход; в онзи опит след това дойде грешка при изтегляне
Current version: 2.1.241
Checking for updates to latest version...
…
```

#### `claude ultrareview [цел]`

Облачно мултиагентно ревю с отпечатване на находките в терминала. **[извън плана]** При Pro и Max има три безплатни изпълнения – те са еднократни и не се възстановяват, а при Team и Enterprise безплатни няма изобщо; нататък ревюто се таксува от кредитите, обикновено между 5 и 25 долара за изпълнение според размера на промените, а при изключени кредити стартирането просто се блокира. **[не във всички планове]** Нужен е вход в акаунт на claude.ai: през Amazon Bedrock, Google Cloud Agent Platform и Microsoft Foundry, както и в организации със Zero Data Retention командата не е налична.

Разборът не върви на вашата машина: промените отиват в облачна сесия, където няколко агента работят по тях паралелно, а в терминала се връща вече готов списък с находки. Изпълнението се брои от момента, в който облачната сесия е стартирала: ревю, спряно по средата, пак ще изразходва безплатното изпълнение, а платеното ще таксува само за свършената част. Съгласие за таксуване на кредити се иска веднъж за разговор.

```bash
claude ultrareview                        # находките се печатат директно в терминала
```

#### `claude gateway`

Стартира корпоративен шлюз за автентикация и телеметрия. През него разработчиците ходят към API не директно: данните за достъп остават на шлюза, а той събира и статистика за използването – така ключовете не се разпиляват по машините и се вижда кой колко харчи. Конфигурацията се задава с отделен файл чрез флаг. Нещо чисто корпоративно, самостоятелно не ви трябва.

Командата не завършва: това е сървър, който остава в работа, докато не го спрат.

```bash
claude gateway --config gateway.yaml      # корпоративен шлюз
```

#### `claude remote-control`

**Скрита:** държи отдалеченото управление като сървър. Псевдоним: `rc`. Машината при това остава на линия и към нейната сесия може да се свърже от друго устройство, без да се стига до самия компютър. Процесът не завършва сам – живее, докато не го спрете, а `--continue` подхваща последната сесия за управление вместо нова. **[не във всички планове]** Нужен е вход в акаунт на claude.ai – с ключ за API отдалеченото управление не работи.

```bash
claude remote-control --continue          # връщане в последната сесия за управление
```

#### `claude self-hosted-runner`

**Скрита:** превръща машина или контейнер в площадка, където се изпълняват уеб, мобилни и desktop сесии. **[не във всички планове]** Това е публична бета за Team и Enterprise, изключена по подразбиране: собственикът на организацията трябва да разреши самостоятелно хоствани среди, в организацията трябва да е включен уеб Claude Code, а със Zero Data Retention това не работи. Отделна такса за такава площадка няма – хардуерът е ваш, а сесиите на него изразходват същия лимит на организацията като сесиите върху инфраструктурата на Anthropic.

Има подкоманда `setup` и отделен оркестратор, който вдига изпълнители, когато се натрупа опашка, а флаговете са към двадесет: адрес на API, файл с тайната на средата, папка с хукове, порт за проверка на здравето, капацитет, таймаути за източване и спиране, време на живот на неактивен изпълнител, етикет на клиента. Всичко това е описано в отделен наръчник за самостоятелно хоствани среди – въпреки разпространеното мнение, че подкомандата е недокументирана.

```bash
claude self-hosted-runner setup           # подготвя машината като площадка
```

### Инсталиране и обновяване

Начините са повече от `npm install` и това си струва да се знае, защото нативният билд се обновява сам, а пакетът от npm – не.

```bash
# macOS, Linux, WSL – нативен инсталатор
curl -fsSL https://claude.ai/install.sh | bash
curl -fsSL https://claude.ai/install.sh | bash -s stable     # закрепва канала
curl -fsSL https://claude.ai/install.sh | bash -s 2.1.236    # закрепва версията

# Windows
irm https://claude.ai/install.ps1 | iex                      # PowerShell
winget install Anthropic.ClaudeCode                          # или с пакетен мениджър

# macOS през Homebrew – два различни пакета
brew install --cask claude-code                              # стабилен, изостава с около седмица
brew install --cask claude-code@latest                       # свеж

# npm – работи, но изисква Node 22+
npm install -g @anthropic-ai/claude-code
```

Има и подписани хранилища за apt, dnf и apk. А `claude install` и `claude update` работят, когато Claude Code вече е инсталиран.

### Кодове на изход

Раздел от три реда, но за скриптовете е важен.

| Код | Какво означава |
|---|---|
| 0 | Успех |
| различен от нула | Стартирането не е успяло |
| 143 | Прекъснато със сигнал за завършване |
| 137 | Инсталирането е убито преди края |

Тънкост: неверният флаг се съобщава в потока за грешки **преди** началото на работата, а срив по време на работата – например липса на автентикация – се печата като резултат в обикновения изход. Тоест само по кода на връщане не може да се различи „не е стартирало“ от „стартира и не успя“.

Прекъсването със сигнал оставя текущия ход недовършен и без резултат, убива дървото от процеси на стартираните команди, изпълнява хуковете за край на сесията – и при възобновяване на сесията този ход ще продължи от мястото на спиране.

### Флагове за стартиране

Отметката **[няма в справката]** означава, че флагът работи, но `claude --help` в билд 2.1.251 не го печата.

#### Сесия и нейното продължаване

| Флаг | Какво прави |
|---|---|
| `-c`, `--continue` | Продължава последния разговор в текущата папка. Пропуска фоновите сесии. |
| `-r`, `--resume [стойност]` | Продължава по идентификатор или отваря интерактивен избор. |
| `--fork-session` | При продължаване заделя нов идентификатор вместо преизползване на стария. |
| `--session-id <uuid>` | Задава конкретен идентификатор на сесията. |
| `-n`, `--name <име>` | Показвано име на сесията. |
| `--from-pr [стойност]` | Продължава сесията, свързана с pull request. |
| `--no-session-persistence` | Не записва сесията на диска. Само с неинтерактивния режим. |
| `--teleport [сесия]` | Взема уеб сесия в терминала. |
| `--cloud [описание\|id\|адрес]` | Създава облачна сесия или се свързва със съществуваща. |
| `--remote` | **[остар]** Старото име на `--cloud`. Среща се в чужди скриптове. |
| `--environment <id>` | Създава облачна сесия върху собствена среда. |
| `--ref <клон>` | **[няма в справката]** С кой ref да се разгърне облачната среда. Работи заедно с `--environment`. |
| `--remote-control [име]`, `--rc` | Стартира сесия с включено отдалечено управление. |
| `--remote-control-session-name-prefix <префикс>` | Префикс за автоматичните имена на такива сесии. |
| `--bg`, `--background` | Стартира във фонов режим и връща управлението; печата идентификатор. |
| `--exec <команда>` | **[няма в справката]** Стартира не сесия, а обикновена команда като фонова задача. |
| `-w`, `--worktree [име]` | Създава ново работно копие на git за сесията. |
| `--tmux` | Вдига tmux сесия за работното копие. |
| `--teammate-mode <режим>` | **[няма в справката]** Как да се показват тиймейтите: `in-process`, `auto`, `tmux`, `iterm2`. |

```bash
claude -c                                # продължава последния разговор
claude -r                                # избор от списък
claude -r 8f3c1d2e --fork-session        # продължава с копие, без да пипа оригинала
claude -n "рефакторинг на плащането"      # стартира с име
claude --from-pr 1234                    # сесия по pull request
claude --bg "изпълни целия тест сюит"     # във фонов режим, ще върне id
claude --bg --exec 'pytest -x'           # фонова задача изобщо без сесия
claude -w feature-x                      # собствено работно копие за сесията
claude -w feature-x --tmux               # същото в tmux
claude --cloud "поправи флейкове в CI"    # облачна сесия
claude --environment ccpool_abc --ref main -p "изпълни димните тестове"
```

Флагът `--exec` заслужава отделен ред: той превръща CLI в стартер на фонови задачи изобщо без модел. Командата се изпълнява в псевдотерминал, изходът ѝ се чете през `claude logs`, а спира се с `claude stop`. Удобно е, когато трябва един общ начин да се следят дълги процеси.

#### Изход и неинтерактивен режим

| Флаг | Какво прави |
|---|---|
| `-p`, `--print` | Отпечатва отговора и излиза. Диалогът за доверие към папката се пропуска. |
| `--output-format <формат>` | `text` по подразбиране, `json` или `stream-json`. |
| `--input-format <формат>` | `text` по подразбиране или `stream-json`. |
| `--json-schema <схема>` | Схема за валидация на структурирания отговор. |
| `--include-partial-messages` | Връща части от съобщенията, докато постъпват. |
| `--include-hook-events` | Включва в потока събитията от жизнения цикъл на хуковете. |
| `--forward-subagent-text` | Предава текста и разсъжденията на субагентите. |
| `--replay-user-messages` | Връща потребителските съобщения обратно в изхода. |
| `--max-turns <n>` | **[няма в справката]** Таван на броя ходове с инструменти. Главният лост за контрол на разходите в CI. |
| `--max-budget-usd <сума>` | Таван на разходите за извикванията на API. |
| `--permission-prompt-tool <инструмент>` | **[няма в справката]** MCP инструмент, който отговаря на заявките за разрешения вместо човека. |
| `--ax-screen-reader` | Прост текст без рамки и анимации. |
| `--verbose` | Замества съответната настройка от файла. |

```bash
claude -p "изброй публичните ендпойнти" --output-format json | jq -r '.result'
claude -p "изготви отчет" --json-schema ./report.schema.json | jq '.structured_output'
claude -p "поправи линтера" --max-turns 5            # таван на ходовете
claude -p "провери стила" --max-budget-usd 0.50      # таван на разходите
claude -p "..." --permission-prompt-tool mcp_auth_tool
cat diff.patch | claude -p "оцени риска от тези промени"
```

Два флага тук са най-полезните и същевременно липсват в справката. `--max-turns` ограничава броя на ходовете с извикване на инструменти; при достигане на тавана изпълнението завършва със съответен признак в резултата и именно него официално препоръчват като основен лост за контрол на цената в CI. `--permission-prompt-tool` назовава MCP инструмент, който ще отговаря на заявките за разрешения вместо човека – единственият начин да получите логика за одобрение при неинтерактивно стартиране.

#### Какво трябва да знаете за неинтерактивния режим

**Слеш командите в него работят.** Собствените скилове и команди се вмъкват директно в текста на промпта. Вградени терминални команди като `/login` там няма, но `/model`, `/effort`, `/fast`, `/color` и `/rename` приемат стойност като аргумент, а `/mcp` без аргумент печата текстова справка за сървърите. Настройките се променят чрез `/config ключ=стойност`.

```bash
claude -p "/model sonnet /code-review low"
claude -p "/config thinking=false разкажи какво прави този модул"
```

**Форматът `json` връща значително повече от текста на отговора.** Ето истински отговор на тривиална заявка, снет от билд 2.1.252 и съкратен – изхвърлени са само повтарящите се броячи:

```json
{
  "type": "result",
  "subtype": "success",
  "is_error": false,
  "result": "ок",
  "session_id": "8a792c19-cd74-4531-8311-f5cab07771d8",
  "num_turns": 1,
  "total_cost_usd": 0.351315,
  "duration_ms": 4988,
  "duration_api_ms": 2029,
  "ttft_ms": 2271,
  "stop_reason": "end_turn",
  "terminal_reason": "completed",
  "usage": {
    "input_tokens": 2,
    "output_tokens": 4,
    "cache_creation_input_tokens": 34368,
    "cache_read_input_tokens": 15050,
    "service_tier": "standard"
  },
  "modelUsage": {
    "claude-opus-5": {
      "inputTokens": 2,
      "outputTokens": 4,
      "costUSD": 0.351315,
      "contextWindow": 1000000,
      "maxOutputTokens": 64000,
      "provider": "firstParty"
    }
  },
  "permission_denials": [],
  "subagent_stats": { "spawned": 0, "completed": 0, "failed": 0 },
  "fast_mode_state": "off",
  "fast_mode_disabled_reason": "sdk_opt_in_required"
}
```

Тук си струва да се обърне внимание на три неща. Текстът на отговора е в `result` – това е онова, заради което обикновено се вика `jq -r '.result'`. Цената в `total_cost_usd` се изчислява от клиента, а не от сървъра, и е разбита по модели в `modelUsage`. А `usage` показва накъде наистина са отишли парите: в примера по-горе на четири токена отговор се падат тридесет и четири хиляди токена запис в кеша – тоест плащате за контекста, а не за отговора. При схема за валидация структурираният отговор се поставя в отделно поле до същите метаданни.

`session_id` може да се запази и разговорът да се продължи по-късно – при това от друга папка, считано от версия 2.1.223.

**Конфликти на флагове.** `-p` заедно с `--bg` е грешка. `--cloud` с описание на задача заедно с `-p` – също; докато `--cloud <id>` заедно с `-p` ще постави съобщение в опашката на тази облачна сесия и ще излезе.

**Ограничения на потока.** Входът по конвейер е ограничен до десет мегабайта: повече – ясна грешка и ненулев код. Ако входният поток изобщо не се чете, ще има предупреждение, а работата ще продължи с промпта от командния ред.

**Фоновите задачи завършват заедно със стартирането.** Команда, пусната във фонов режим по време на `claude -p`, се прекратява около пет секунди след като е отпечатан резултатът. Фоновите субагенти и работните процеси са изключение, тях ги чакат, но не повече от десет минути непрекъснато бездействие.

**`--bare` е препоръчителният режим за скриптове** и в бъдеще ще стане поведение по подразбиране за `-p`. Разликата е съществена: без него неинтерактивното стартиране изпълнява хуковете от `.claude/settings.json` на проекта и свързва сървърите от неговия `.mcp.json` **дори в папка, на която никога не сте давали доверие**, без нито един въпрос.

#### Модел, усилие, режим на правата

| Флаг | Какво прави |
|---|---|
| `--model <модел>` | Алиас (`fable`, `opus`, `sonnet`, `haiku`) или пълно име. |
| `--fallback-model <модел,...>` | Връщане към друг модел при претоварване на основния. Само с `-p`. |
| `--effort <ниво>` | `low`, `medium`, `high`, `xhigh`, `max`, а според документацията и `ultracode`. |
| `--advisor <модел>` | **[няма в справката]** Включва съветник и му задава модел. |
| `--agent <агент>` | Агент за сесията; има предимство пред настройката. |
| `--agents <json>` | Обявява собствени агенти направо в командния ред. Проверява се при стартиране. |
| `--permission-mode <режим>` | `default` (той е и `manual`), `acceptEdits`, `plan`, `auto`, `dontAsk`, `bypassPermissions`. |
| `--dangerously-skip-permissions` | Заобикаля проверките на правата. |
| `--allow-dangerously-skip-permissions` | Прави заобикалянето достъпен вариант, без да го включва. |
| `--restricted` | Ограничен режим. |
| `--safe-mode` | Изключва всички персонализации. |
| `--bare` | Минимален режим за скриптове. |

```bash
claude --model haiku -p "изброй променените файлове"
claude --effort xhigh                    # сесия с дълбоки разсъждения
claude --effort ultracode                # веднага с оркестрация на работни процеси
claude --advisor opus                    # включва съветник
claude --permission-mode plan            # стартира в режим на планиране
claude --permission-mode acceptEdits     # автоматично приема редакциите
claude --safe-mode                       # без хукове, скилове, плъгини и MCP
claude --bare -p "..."                   # минимален режим за скрипт
```

Три предупреждения. **`--dangerously-skip-permissions` не работи под администратор:** на Linux и macOS стартирането от root или през sudo се отхвърля, защото root плюс липса на въпроси е достъп до всичко на машината. Вътре в разпознат пясъчник проверката се премахва. Организацията може напълно да забрани режима с ключа `disableBypassPermissionsMode`.

**Документацията и бинарният файл се разминават на две места.** При `--permission-mode` документацията изброява и `default`, и `manual` като негов псевдоним, а справката на бинарния файл – само `manual`. При `--effort` документацията знае `ultracode`, справката – не. И в двата случая работи по-широкият вариант.

**`--safe-mode` и `--bare` са различни неща.** Първият изключва цялата персонализация за диагностика. Вторият е минимален режим на изпълнение за скриптове, където и автентикацията върви строго с ключ. За дебъгване на „нещо се счупи след моите настройки“ ви трябва първият.

#### Инструменти, папки, MCP

| Флаг | Какво прави |
|---|---|
| `--tools <инструменти...>` | Набор от вградени инструменти: празен низ изключва всички, `default` включва всички, или се изброяват имена. |
| `--allowedTools`, `--allowed-tools` | Разрешава инструменти със списък. И двете форми работят. |
| `--disallowedTools`, `--disallowed-tools` | Забранява инструменти със списък. |
| `--add-dir <папки...>` | Допълнителни работни папки. |
| `--mcp-config <конфигурации...>` | Зарежда MCP сървъри от файлове или низове JSON. |
| `--strict-mcp-config` | Използва само сървърите от този флаг. |
| `--plugin-dir <път>` | Зарежда плъгин от папка или архив само за тази сесия. |
| `--plugin-url <адрес>` | Същото, но архив по връзка. |
| `--channels <сървъри...>` | **[няма в справката]** Кои MCP сървъри да се слушат за външни събития. |
| `--dangerously-load-development-channels` | **[няма в справката]** Разрешава канали извън одобрения списък. |
| `--disable-slash-commands` | Изключва всички скилове. |
| `--chrome`, `--no-chrome` | Включва или изключва интеграцията с Chrome. |
| `--ide` | Автоматично се свързва с IDE, ако подходящата е точно една. |

И двата списъка с инструменти приемат изброяване както със запетая, така и с интервал. С `-p` сървърите от `--mcp-config` се очакват до първия ход, но не по-дълго от таймаута за стартиране; некоректен запис се пропуска, а работата продължава и завършва нормално – тоест **в CI трябва да се проверява не кодът на връщане, а списъкът с грешки на сървърите в първото събитие на потока.**

#### Настройки, промпт, останало

| Флаг | Какво прави |
|---|---|
| `--settings <файл-или-json>` | Допълнителни настройки: път до файл или низ JSON. |
| `--setting-sources <източници>` | Кои слоеве настройки да се зареждат: `user`, `project`, `local`. |
| `--system-prompt <промпт>` | Заменя изцяло системния промпт. |
| `--system-prompt-file <път>` | **[няма в справката]** Същото, но от файл. |
| `--append-system-prompt <промпт>` | Дописва към системния промпт. |
| `--append-system-prompt-file <път>` | **[няма в справката]** Същото, но от файл. |
| `--append-subagent-system-prompt <текст>` | **[няма в справката]** Дописва към системния промпт на всеки субагент. |
| `--exclude-dynamic-system-prompt-sections` | Изнася зависещите от машината части в първото потребителско съобщение – кешът се преизползва по-добре. |
| `--autocompact <auto\|токени>` | Праг за автоматично свиване. |
| `--betas <бети...>` | Beta хедъри в заявките. |
| `--init` | **[няма в справката]** Изпълнява хуковете за инициализация преди сесията. Само с `-p`. |
| `--init-only` | **[няма в справката]** Изпълнява хуковете за старт и излиза, без да започва разговор. |
| `--maintenance` | **[няма в справката]** Изпълнява хуковете за поддръжка. Само с `-p`. |
| `--file <id:път ...>` | Изтегля файлови ресурси при стартиране. |
| `--prompt-suggestions [вкл]` | Подсказки за следващия промпт. |
| `--brief` | Включва инструмента за общуване на агента с потребителя. |
| `-d`, `--debug [филтър]` | Режим за дебъгване с филтър по категории. |
| `--debug-file <път>` | Пише лога за дебъгване във файл. |
| `-v`, `--version` | Версия. |
| `-h`, `--help` | Справка. |

```bash
claude --settings '{"disableAllHooks": true}' -p "..."   # стартиране без хуковете на хранилището
claude --setting-sources user -p "..."                   # игнорира настройките на проекта
claude --append-system-prompt-file ./team-rules.md
claude --append-subagent-system-prompt "винаги посочвай пътищата до файловете"
claude --init-only                                       # загрява контейнера и излиза
claude -d "api,hooks"                                    # дебъгване по категории
claude -d "!1p,!file" --debug-file ./claude.log          # всичко, освен тези категории
```

За `--init-only` си струва да кажем отделно: това е естественият начин да се загрее контейнер или работна папка в CI – изпълняват се хуковете за инсталиране и старт на сесията, след което процесът завършва, без да започва разговор.

И за разминаването, което си струва да запомните, ако пишете скриптове по документацията: **`-v` в билд 2.1.251 е `--version`**, макар документацията да твърди, че това е късата форма на `--verbose`. Проверете на вашата версия, преди да разчитате на него.

## Какво го няма в никоя документация

Уговорка за напред: щом тези неща ги няма в документацията, никой не е обещавал да ги запази. Да градите върху тях автоматизация е осъзнат риск.

**Петнадесетина команди за артефакти.** В официалния справочник от тази група има само `/artifacts`, `/design`, `/design-login` и `/design-sync`. Всичко останало – `/prototype`, `/doc`, `/plan-artifact`, `/artifact-pr-review`, `/artifact-dashboard`, `/artifact-report`, `/artifact-data-table`, `/artifact-explainer`, `/artifact-components`, `/artifact-design`, `/artifact-diagramming`, `/artifact-capabilities` – не се споменава никъде. Към тях спадат и `/whiteboard`, `/whiteboard-mp` и `/workshop`.

**Седем подкоманди на `/design`.** Официално това е една команда, приемаща описание на дизайн. В бинарния файл тя разбира `sync`, `login`, `consent`, `revoke`, `import`, `export` и `status`.

**Диагностика на собствения разход.** `/skill-doctor`, който показва неизползваните скилове, и `/explain-usage`, който обяснява разхода с човешки език, не са документирани нито единият, нито другият. Както и `/plugin-types`, който генерира типове на свързаните MCP инструменти.

**Още пет команди от всекидневния обиход.** `/brief` – режим на кратки отговори. `/daemon` – управление на фоновите услуги. `/cloud-plugins` – плъгини в облачните сесии. `/session` (псевдоним `/remote`) – адрес на отдалечената сесия и QR код към нея; в справочника има `/remote-control` и `/teleport`, а този ред го няма. И `/install`, който инсталира нативния билд направо от сесията.

**Вградени скилове, които ползват всички.** `/commit`, `/pr`, `/update-config`, `/claude-code-docs`, `/claude-in-chrome` не са описани нито в справочника на командите, нито в раздела за вградените скилове. Единственото косвено споменаване в журнала на промените е поправка на грешка, при която агентът викал несъществуващ скил за комит.

**Команди, изключени в този билд.** `/version`, `/update`, `/loops`, `/wellbeing` с всичките им псевдоними и `/pause-memory` – регистрирани са, но не работят. Нито една от тях не е спомената в журнала на промените – нито като премахната, нито като добавена: `/version`, `/wellbeing` и `/pause-memory` не се срещат там изобщо нито веднъж за цялата история, а споменаванията на `/update` са поправки на грешки, където тя още работи.

**Команди, които се появяват според състоянието.** `/limit-reset`, `/low-priority`, `/pro-trial-expired`, `/design-consent`, `/design-revoke` и свързаната с режима Cowork `/setup-cowork`. Документацията признава точно една скрита команда – снемането на дъмп на паметта – и отделно споменава, че настройката на доставчиците се появява заедно с променлива на средата. За тези шест няма нищо.

**Вътрешни входове и скилове само за модела.** `__remote-workflow` и `workflow-launch-exec`, през които сървърът предава на сесията готов работен процес. И три скила, които агентът дърпа сам, а да се наберат не могат: `keybindings-help`, `memory-types`, `cowork-plugin`. Механизмът – полето `user-invocable: false` – е описан, а самите скилове – не.

**Устройството на `/code-review` отвътре.** Документацията описва нивата качествено. Колко независими ъгъла на търсене има, колко кандидата на ъгъл и какъв е таванът на находките на всяко ниво, както и това, че на Opus 5 средното и високото ниво в момента се свеждат до един проход – това го няма никъде. Както и трите правила за разбор на аргументите, заради които `ultra` работи само като първа дума.

**Формата `/sandbox exclude "шаблон"`.** Официалният ред за тази команда е едно изречение: превключва режима на пясъчника. За извеждането на отделни команди изпод изолацията и за подкомандата за доинсталиране на Windows не се казва нищо.

**Псевдонимът `/name` на командата `/rename`.** Редът за самата команда в справочника е необичайно подробен – със санитизация на името и лимит на дължината, – но псевдоним в него няма.

**Флагът `--file`.** Изтеглянето на файлови ресурси при стартиране го няма в списъка с флагове.

**Осем ключа на настройките.** За тях няма нито ред нито в документацията, нито в журнала на промените, нито в публикуваната схема: `doneMeansMerged` – „готово значи слято“; `breakReminder` и `quietHours` – напомняния за почивки и тихи часове (в търсачката се намира статия за потребителското приложение на Claude, но това е друго и без ключове за настройки); `precomputeCompactionEnabled`; `daemonColdStart`; `defaultView`; `autoUploadSessions`; `showMessageTimestamps`. Плюс `xaaIdp` заедно с включващата го променлива, `syncClaudeAiPlugins` – при положение че неговият събрат `syncClaudeAiSkills` е документиран, – и `proxyAuthHelper`.

**Ключове, които ги има само в публикуваната схема.** `sandbox.enabledPlatforms`, `skippedMarketplaces` и `skippedPlugins` – нула споменавания в документацията и журнала на промените, схемата остава единствената им публична следа.

**Осем променливи на средата.** Официалната страница изброява триста четиридесет и девет и тези ги няма сред тях: `CLAUDE_CODE_GOAL_CHECKIN_MINUTES`, `CLAUDE_CODE_WORKFLOW_PREFIX_STAGGER_MS`, `CLAUDE_CODE_DISABLE_AGENT_VIEW`, `CLAUDE_CODE_DISABLE_WORKFLOWS`, `CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING`, `CLAUDE_CODE_DISABLE_CLAUDE_MDS`, `CLAUDE_CODE_SHELL` заедно с `CLAUDE_CODE_SHELL_PREFIX` и `USE_BUILTIN_RIPGREP`. За част от тях има документирани съседи с други имена и малко различен смисъл – например за изключване на разсъжденията или за превключване на търсенето на файлове, – но това не са те.

**Подкомандата `claude plugin eval`.** Изпълнение на проверочни случаи срещу плъгин: в справочника за плъгините са изброени десет подкоманди и тази я няма сред тях.

**И отсъствието на онова, което го няма.** Командата `/init-verifiers` не съществува, `/alias` не е слеш команда, а файл `.claudeignore` няма изобщо. За несъществуващото документацията, естествено, мълчи – а статия в интернет няма.

Отделно си струва да се каже за числото. В официалния справочник има сто и единадесет реда и там честно е написано, че не всяка команда е достъпна за всеки. Колко са регистрирани общо, не се публикува; в билд 2.1.251 излизат около сто и петдесет заедно със скиловете. Community шпаргалките наричат ту двеста седемдесет и две (като броят и флаговете на командния ред), ту около седемдесет – и двете цифри не се основават на нищо.

## С какво да започнете, ако всичко това го виждате за първи път

Таблиците са много и първото желание е да затворите страницата. Затова – кратък практичен минимум: какво си струва да се настрои в първия ден и към какво да се връщате при нужда.

**Веднага, в потребителския файл.** Правата на инструментите: без тях ще ви питат за всеки билд и за всеки `git status` и след час ще започнете да натискате „разреши“, без да четете – а това е точно навикът, заради който после нещо се изтрива. Статус лентата: постоянно видимият разход и запълването на контекста променят поведението ви по-силно от всякакви благи намерения. И по-голямо `cleanupPeriodDays`, ако смятате някой ден да търсите стар разговор или да се връщате към контролна точка.

**В проекта, с комит в хранилището.** Разрешенията за командите именно на този проект, хуковете, които пазят инвариантите, и `.mcp.json` със сървърите, нужни на целия екип.

**За по-късно.** Пясъчникът, самостоятелно хостваните среди, корпоративните ключове. Те решават задачи, които най-вероятно още нямате; а раздела за пясъчника си струва да прочетете точно в деня, в който за първи път пуснете агент със заобикаляне на потвържденията.

Файл, с който може нормално да се започне:

```json title="~/.claude/settings.json"
{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "cleanupPeriodDays": 365,
  "fileCheckpointingEnabled": true,
  "permissions": {
    "allow": [
      "Bash(git status)",
      "Bash(git diff:*)",
      "Bash(git log:*)",
      "Bash(npm run build)",
      "Bash(npm test:*)"
    ],
    "ask": ["Bash(git push:*)"],
    "deny": ["Read(./.env)", "Read(./.secrets/**)"]
  },
  "statusLine": {
    "type": "command",
    "command": "~/.claude/statusline.sh"
  }
}
```

Пет разрешения – това вече са забележимо по-малко въпроси. Една забрана за файла с тайните – защото забраната побеждава разрешението и това е най-евтиният начин да се гарантира, че съдържанието на `.env` никога няма да попадне в контекста. Контролните точки са включени изрично: без тях `/rewind` няма да върне нито един файл, а това обикновено се разбира в неподходящ момент.

## Източници

Всичко, на което се крепи статията, е с линкове. Документацията на Claude Code живее на `code.claude.com/docs`; старите адреси на `docs.claude.com` пренасочват натам, така че отметки отпреди година водят не там, където сте свикнали.

| За какво в статията | Страница от документацията |
|---|---|
| Слеш команди: списък, аргументи, версии | [commands](https://code.claude.com/docs/en/commands) |
| Бързи клавиши и поведение на полето за въвеждане | [interactive-mode](https://code.claude.com/docs/en/interactive-mode) |
| Ревю: нива, флагове, цел | [code-review](https://code.claude.com/docs/en/code-review) |
| Облачно ревю: лимити на диф и цена | [ultrareview](https://code.claude.com/docs/en/ultrareview) |
| Правила за права: синтаксис, котви на пътищата, защитени пътища | [permissions](https://code.claude.com/docs/en/permissions) |
| Режими на права, включително `dontAsk` | [permission-modes](https://code.claude.com/docs/en/permission-modes) |
| Настройки: къде са и кой кого замества | [settings](https://code.claude.com/docs/en/settings) |
| Всеки ключ на настройките поотделно | [settings-reference](https://code.claude.com/docs/en/settings-reference) |
| Корпоративни настройки и източници на политика | [managed-settings](https://code.claude.com/docs/en/managed-settings) |
| Променливи на средата – всичките 349 | [env-vars](https://code.claude.com/docs/en/env-vars) |
| Телеметрия, метрики и събития | [monitoring-usage](https://code.claude.com/docs/en/monitoring-usage) |
| Хукове: събития, кодове на изход, матчъри | [hooks](https://code.claude.com/docs/en/hooks) |
| Терминални подкоманди и флагове за стартиране | [cli-reference](https://code.claude.com/docs/en/cli-reference) |
| Неинтерактивен режим и формати на изхода | [headless](https://code.claude.com/docs/en/headless) |
| MCP: транспорти, обхвати, таймаути | [mcp](https://code.claude.com/docs/en/mcp) |
| Скилове и форматът `SKILL.md` | [skills](https://code.claude.com/docs/en/skills) |
| Субагенти и техният frontmatter | [sub-agents](https://code.claude.com/docs/en/sub-agents) |
| Плъгини, манифест и маркетплейси | [plugins-reference](https://code.claude.com/docs/en/plugins-reference) |
| Памет на проекта и `CLAUDE.md` | [memory](https://code.claude.com/docs/en/memory) |
| Пясъчник: файлове, мрежа, тайни | [sandboxing](https://code.claude.com/docs/en/sandboxing) |
| Контролни точки и `/rewind` | [checkpointing](https://code.claude.com/docs/en/checkpointing) |
| Лимити на плана, кредити, цена | [costs](https://code.claude.com/docs/en/costs) |
| Fast режим и с какво се плаща | [fast-mode](https://code.claude.com/docs/en/fast-mode) |
| Модели, алиаси и кредитни варианти | [model-config](https://code.claude.com/docs/en/model-config) |
| Съветник | [advisor](https://code.claude.com/docs/en/advisor) |
| Задачи по разписание | [routines](https://code.claude.com/docs/en/routines) |
| Авторежим и неговите правила | [auto-mode-config](https://code.claude.com/docs/en/auto-mode-config) |
| Екран на фоновите агенти | [agent-view](https://code.claude.com/docs/en/agent-view) |
| Статус лента | [statusline](https://code.claude.com/docs/en/statusline) |
| Собствени среди за облачни сесии | [self-hosted-environments-reference](https://code.claude.com/docs/en/self-hosted-environments-reference) |
| Ревю в GitHub Actions | [github-actions](https://code.claude.com/docs/en/github-actions) |
| Текстове на грешки и предупреждения | [errors](https://code.claude.com/docs/en/errors) |
| От какво се образува запълването на контекста | [context-window](https://code.claude.com/docs/en/context-window) |

Два източника не са документация и без тях половината статия нямаше да я има. [Журналът на промените](https://raw.githubusercontent.com/anthropics/claude-code/main/CHANGELOG.md) в хранилището `anthropics/claude-code` е единственото място, където е написано какво и в коя версия е премахнато или преименувано; отделна страница с бележки за изданията продуктът вече няма. [Схемата на настройките](https://www.schemastore.org/claude-code-settings.json) знае ключове, които ги няма в документацията, но и изостава от продукта: в нея още стои ключ, премахнат в 2.1.234.

Дословният изход на командите е търсен из [целия корпус на документацията в един файл](https://code.claude.com/docs/llms-full.txt) – така е по-лесно, отколкото да се обикалят сто и деветдесет страници една по една.

И третият източник е самата инсталирана програма. Списъците с команди, ключове на настройки и флагове са снети от нея, а не от документацията: в нея те са повече и на места се разминават. Всичко, което можеше да се провери със стартиране, е проверено със стартиране.