---
title: "Konfiguracja Monolynx: która zmienna w którym pliku"
description: "Gdzie zapisać zmienne MONOLYNX_*: plik śledzony, plik osobisty czy środowisko procesu. Tabela wartości domyślnych, przykłady dla sprintu i pracy ręcznej oraz modele przypisane do ról."
url: "https://monolynx.com/blog/konfiguracja-monolynx-zmienne"
lang: "pl"
author: "Zespół Monolynx"
published: "2026-10-08T08:43:47.777441+00:00"
modified: "2026-10-09T18:11:37.496429+00:00"
last_verified: "2026-10-08"
tags: ["konfiguracja", "plugin", "claude-code", "sprint", "agenci-ai"]
translations: []
reading_time_minutes: 11
word_count: 2039
---

> [!TLDR]
> - Zmienne `MONOLYNX_*` mają trzy miejsca: śledzony plik `.claude/settings.json`, osobisty `.claude/settings.local.json` i środowisko procesu.
> - Sesja w tle pracuje w worktree, a tam trafia tylko to, co zna git. Pliku osobistego nie widzi.
> - Zgody na testy, commit, push i merge request wpisujesz do pliku śledzonego. Branch sprintu ustawiasz w środowisku dyspozytora.
> - Wartości domyślne są zachowawcze: bez flag komenda wypisuje polecenia i czeka na Ciebie.
> - Model każdej roli jest ustawiony jawnie. Domyślnie koordynuje `opus`, a wykonuje `sonnet`.

## Gdzie zapisać zmienną, żeby zadziałała?

Plugin czyta ustawienia ze zmiennych środowiskowych o nazwach zaczynających się od `MONOLYNX_`. Claude Code wstawia je do środowiska sesji z pola `env` w plikach ustawień projektu. O tym, czy zmienna dotrze do sesji, decyduje miejsce zapisu.


**Porównanie**

| Miejsce | Kto je widzi | Do czego służy |
| --- | --- | --- |
| `.claude/settings.json` | każda sesja w repozytorium, także sesja w tle i każdy członek zespołu | ustawienia wspólne projektu |
| `.claude/settings.local.json` | tylko sesje uruchomione w Twoim głównym katalogu repozytorium, w tym dyspozytor | ustawienia osobiste i tymczasowe |
| Środowisko procesu | proces, w którym ustawisz zmienną, i wszystko, co on uruchomi | ustawienia na czas jednego przebiegu, na przykład sprintu |



**Która zmienna dociera do sesji ticketu w tle**

Dyspozytor startuje sesję ticketu w osobnym worktree. Do tej sesji docierają dwie rzeczy: plik śledzony przez gita, bo jest częścią repozytorium, oraz środowisko procesu dyspozytora, bo sesja je dziedziczy. Plik osobisty jest ignorowany przez gita, więc w worktree go nie ma.

```mermaid
flowchart TD
  A[".claude/settings.json (śledzony)"] --> D["Sesja ticketu w worktree"]
  B["Środowisko dyspozytora"] --> D
  C[".claude/settings.local.json (osobisty)"] -. "nie dociera" .-> D
  C --> E["Twoja sesja w głównym katalogu"]
  A --> E
```


> [!WARNING]
> Najczęstszy błąd konfiguracji: zgody wpisane do pliku osobistego. Twoja sesja je widzi, więc wszystko wygląda dobrze. Sesja w tle ich nie widzi i kontrola wstępna dyspozytora zatrzymuje sprint.


**Statystyki**

- **3** - miejsca zapisu zmiennej
- **5** - flag autonomii, wszystkie domyślnie wyłączone
- **3** - zmienne, których nie wolno wpisać do pliku śledzonego


## Co wpisać do pliku śledzonego?

Do pliku śledzonego trafia wszystko, co ma działać tak samo u każdego i w każdej sesji: nazwa projektu i zgody na samodzielne kroki.

```json title=".claude/settings.json: projekt prowadzący sprinty z agentami"
{
  "env": {
    "MONOLYNX_PROJECT_SLUG": "twoj-projekt",
    "MONOLYNX_CONTRACT": "auto",
    "MONOLYNX_AUTOTEST": "true",
    "MONOLYNX_AUTOCOMMIT": "true",
    "MONOLYNX_AUTOPUSH": "true",
    "MONOLYNX_AUTOMR": "true"
  }
}
```

Trzy z tych flag są warunkiem startu sprintu. Bez `MONOLYNX_AUTOTEST`, `MONOLYNX_AUTOCOMMIT` i `MONOLYNX_AUTOPUSH` dyspozytor nie uruchomi żadnej sesji. `MONOLYNX_AUTOMR` jest zalecana: bez niej branch ticketu zostaje wypchnięty, ale merge request tworzysz sam.

> [!NOTE]
> Skrypt `sprint_run.sh` ustawia te flagi sam dla procesów, które uruchamia. Jeśli sprint prowadzisz wyłącznie tym skryptem, plik śledzony może ich nie zawierać. Pętla `/loop` w sesji interaktywnej wymaga ich w pliku albo w środowisku.

### Projekt, w którym pracujesz ręcznie

Bez sprintu z agentami wystarcza znacznie mniej. Poniższy przykład zostawia Ci commit i push, a oddaje agentowi tylko lint i testy.

```json title=".claude/settings.json: praca ręczna, ticket po tickecie"
{
  "env": {
    "MONOLYNX_PROJECT_SLUG": "twoj-projekt",
    "MONOLYNX_AUTOTEST": "true"
  }
}
```

## Czego nie wpisywać do pliku śledzonego?

Trzy zmienne opisują jeden przebieg, a nie projekt. Wpisane do pliku śledzonego trafiłyby po merge do każdej sesji każdej osoby.


**Porównanie**

| Zmienna | Gdzie ją ustawić | Co by się stało w pliku śledzonym |
| --- | --- | --- |
| `MONOLYNX_MR_TARGET` | środowisko dyspozytora albo plik osobisty | po zakończeniu sprintu tickety dalej szłyby do starego brancha sprintu |
| `MONOLYNX_BASE_BRANCH` | zwykle nigdzie; wystarcza `MONOLYNX_MR_TARGET` | to samo co wyżej |
| `MONOLYNX_SPRINT_RUN` | nigdzie; dyspozytor dopisuje ją sam do komendy startu sesji | każda zwykła sesja zachowywałaby się jak sesja w tle i zamiast pytać, odmawiała |



**Branch sprintu ustawiony w środowisku dyspozytora**

```console
$ git switch sprint/eksport-zamowien
$ export MONOLYNX_MR_TARGET=sprint/eksport-zamowien
$ claude
> /loop 15m /monolynx:sprint-run
```


Sesje ticketów startowane przez dyspozytora dziedziczą jego środowisko, więc każda z nich wie, do którego brancha ma otworzyć merge request. Plik osobisty działa tu tylko pośrednio: czyta go sesja dyspozytora w głównym katalogu i przekazuje wartość dalej, a sama sesja ticketu tego pliku nie widzi. Najpewniejszy jest `export` w terminalu, z którego startujesz pętle. Kolejka `mr-queue` bierze branch docelowy z samego merge requesta, więc w jej oknie zmienna nie jest potrzebna. Jeśli ją tam ustawisz, musi mieć tę samą wartość. Katalog, z którego startujesz dyspozytora, musi stać na tym samym branchu, bo worktree ticketu powstaje z jego bieżącego commita.

> [!IMPORTANT]
> `MONOLYNX_BASE_BRANCH` i `MONOLYNX_MR_TARGET` nazywają ten sam branch: ticket startuje z brancha, do którego wraca jego merge request. Ustaw jedną, `MONOLYNX_MR_TARGET`. Dwie różne wartości zatrzymują dyspozytora i kolejkę komunikatem błędu.

## Zmienne i ich wartości domyślne

Poniższe tabele zbierają zmienne, których używa się najczęściej. Kolumna "Domyślnie" mówi, co się stanie, gdy zmiennej nie ustawisz.

### Projekt i zgody


**Porównanie**

| Zmienna | Domyślnie | Co zmienia |
| --- | --- | --- |
| `MONOLYNX_PROJECT_SLUG` | brak | nazwa projektu na platformie; bez niej komenda pyta |
| `MONOLYNX_AUTOTEST` | `false` | `true`: agent sam uruchamia lint i testy |
| `MONOLYNX_AUTOCOMMIT` | `false` | `true`: commit po zielonych testach |
| `MONOLYNX_AUTOPUSH` | `false` | `true`: push bez pytania |
| `MONOLYNX_AUTOMR` | `false` | `true`: merge request po pushu; działa tylko razem z dwiema poprzednimi |
| `MONOLYNX_AUTOMERGE` | `false` | `true`: kolejka merguje gotowy merge request bez pytania |
| `MONOLYNX_CONTRACT` | `ask` | `auto`: kontrakt autonomii jest zapisywany, a praca idzie dalej bez potwierdzenia |


### Branche


**Porównanie**

| Zmienna | Domyślnie | Co zmienia |
| --- | --- | --- |
| `MONOLYNX_MR_TARGET` | domyślny branch repozytorium | branch, do którego idzie merge request ticketu |
| `MONOLYNX_BASE_BRANCH` | wartość `MONOLYNX_MR_TARGET` | branch, z którego powstaje branch ticketu |
| `MONOLYNX_BRANCH_MODE` | `ticket` | kontrola nazwy brancha: `ticket` wymaga klucza ticketu w nazwie, `sprint` dopuszcza jeden branch na cały sprint, `off` wyłącza kontrolę |
| `MONOLYNX_MERGE_METHOD` | `merge` | sposób merge w kolejce: `merge`, `squash` albo `rebase`; wykonuje go platforma w chwili merge |


### Sprint i pętle


**Porównanie**

| Zmienna | Domyślnie | Co zmienia |
| --- | --- | --- |
| `MONOLYNX_SPRINT_PARALLEL` | `2` | liczba sesji ticketów pracujących jednocześnie |
| `MONOLYNX_SPRINT_MAX_WAITING` | `2` | limit sesji czekających na człowieka; po jego osiągnięciu dyspozytor nie startuje nowych |
| `MONOLYNX_SPRINT_STALL_TICKS` | `2` | po tylu tickach bez zmiany w logu sesja jest uznawana za czekającą |
| `MONOLYNX_SPRINT_PERMISSION_MODE` | `auto` | tryb uprawnień sesji w tle |
| `MONOLYNX_SPRINT_RUNTIME` | `claude` | klient prowadzący sprint: `claude` albo `codex` |


### CLI i skrypty CI

Plugin, CLI i skrypty CI czytają różne zmienne, choć część z nich niesie tę samą informację. Nazwę projektu plugin bierze z `MONOLYNX_PROJECT_SLUG`, a CLI z `MONOLYNX_PROJECT`.


**Porównanie**

| Zmienna | Kto ją czyta | Co zmienia |
| --- | --- | --- |
| `MONOLYNX_PROJECT_SLUG` | komendy pluginu, skrypty w `cicd/` | nazwa projektu na platformie |
| `MONOLYNX_PROJECT` | CLI `monolynx` | nazwa projektu dla komend CLI; to samo co flaga `--project` |
| `MONOLYNX_ENDPOINT` | CLI `monolynx` | adres instancji; domyślnie `https://monolynx.com` |
| `MONOLYNX_URL` | skrypty w `cicd/` | adres instancji; domyślnie `https://monolynx.com` |
| `MONOLYNX_TOKEN` | CLI `monolynx` | token API zamiast logowania; przydatny w CI |
| `MONOLYNX_PROFILE` | CLI `monolynx` | nazwany profil konfiguracji CLI |
| `MONOLYNX_GRAPH_TOKEN` | `cicd/sync_graph.py` | token synchronizacji grafu kodu; bez niego etap jest pomijany |
| `MONOLYNX_MCP_TOKEN` | `cicd/wiki_post_merge.py`, ręczna konfiguracja MCP | token dostępu do serwera MCP |


### Pozostałe


**Porównanie**

| Zmienna | Domyślnie | Co zmienia |
| --- | --- | --- |
| `MONOLYNX_TRANSPORT` | brak | `mcp`: komendy pomijają CLI i pracują tylko przez MCP |
| `MONOLYNX_BRIEF_GUARD` | `auto` | reakcja na gołe polecenie: `auto` proponuje kontrakt, `block` odrzuca, `off` wyłącza |
| `MONOLYNX_MUTATION_BUDGET` | `600` | limit czasu testów mutacyjnych w sekundach; 600 to maksimum |



**Zmienne, których zwykle nie ruszasz**

| Zmienna | Domyślnie | Co zmienia |
| --- | --- | --- |
| `MONOLYNX_SPRINT_RUN_MODE` | brak | `batch` ustawia sam skrypt pętli; nie ustawiaj ręcznie |
| `MONOLYNX_SPRINT_TICK_ALLOWED_TOOLS` | lista wbudowana | narzędzia dozwolone dla ticku w skrypcie pętli |
| `MONOLYNX_SPRINT_CODEX_SANDBOX` | `workspace-write` | piaskownica klienta Codex |
| `MONOLYNX_HOOK_ASK_UNSUPPORTED` | `false` | `true`: strażnik komend odmawia zamiast pytać; dla klientów, które pytania nie obsługują |

Pełną tabelę zawiera plik `README` pluginu, sekcja "Zmienne konfiguracyjne".


## Modele i koszt

Proces uruchomiony bez wskazania modelu bierze domyślny model Twojego konta, a subagent dziedziczy model sesji, która go powołała. Oba zachowania są ciche i prowadzą do tego samego: cały sprint pracuje na najdroższym modelu. Plugin ustawia więc model każdej roli jawnie.


**Porównanie**

| Rola | Model domyślny | Jak zmienić |
| --- | --- | --- |
| Dyspozytor w skrypcie `sprint_run.sh` | `opus` | `MONOLYNX_SPRINT_TICK_MODEL` |
| Dyspozytor w pętli `/loop` | model Twojej sesji | `/model` w tej sesji |
| Koordynator ticketu w tle | `opus` | `MONOLYNX_SPRINT_MODEL` |
| Koordynator ticketu uruchomiony ręcznie | model Twojej sesji | `/model` w tej sesji |
| Agent rozpoznający kod | `sonnet` | treść komendy `work` |
| Programista i tester | model z definicji agenta, a bez niej `sonnet` | pole `model` w definicji agenta |
| Krytyk | `opus` | treść komendy `work` |


> [!TIP]
> Nazwa każdej sesji w tle kończy się nazwą modelu, na przykład `sklep-SKL-12-opus`. Jedno spojrzenie na listę `claude agents` wystarcza, żeby sprawdzić, na czym pracuje sprint.

> [!CAUTION]
> Pętla `/loop` wykonuje tick na modelu sesji, w której ją uruchomiłeś. Jeśli ta sesja używa najdroższego modelu, każdy tick dyspozytora też go używa. Przed startem pętli sprawdź model komendą `/model`.

## Jak sprawdzić, co jest ustawione?

Nie musisz czytać plików ręcznie. Komenda `/monolynx:setup` pokazuje każdą flagę z trzech źródeł naraz i ostrzega, gdy flaga jest ustawiona w miejscu, którego sesja w tle nie zobaczy.


**Kroki**

1. **Uruchom checklistę** Wpisz `/monolynx:setup` w katalogu projektu.
2. **Przeczytaj punkt o flagach** Każda flaga ma wartość i źródło: środowisko, plik śledzony albo plik osobisty.
3. **Przenieś zgody do pliku śledzonego** Flagi autonomii z pliku osobistego wpisz do `.claude/settings.json` i zatwierdź zmianę w gicie.
4. **Sprawdź branch** Gdy `MONOLYNX_BASE_BRANCH` i `MONOLYNX_MR_TARGET` są różne, usuń pierwszą.


> [!NOTE]
> Komenda `setup` niczego nie ustawia sama. Pokazuje stan i proponuje zmianę. Flagi autonomii zawsze wpisujesz Ty, bo są Twoją zgodą.

## Najczęstsze pytania


**FAQ**

### Czy zmienną mogę ustawić zwykłym export w terminalu?
Tak, jeśli z tego samego terminala uruchamiasz potem Claude Code albo skrypt pętli. Zmienna działa do zamknięcia terminala. Dla ustawień trwałych użyj pliku.

### Dlaczego sesja w tle nie widzi mojego pliku osobistego?
Sesja w tle pracuje w osobnym katalogu roboczym utworzonym przez gita. Git kopiuje tam tylko pliki, które śledzi, a plik osobisty jest ignorowany.

### Co się stanie, gdy nie ustawię żadnej zmiennej poza nazwą projektu?
Komendy będą działać w trybie zachowawczym. Agent napisze kod, a potem wypisze polecenia testów, commita i pusha i poczeka, aż wykonasz je sam.

### Czy tańszy model dla koordynatora to dobry pomysł?
Koordynator podejmuje decyzje o podziale pracy i ocenia wyniki, więc oszczędność na nim zwykle wraca jako dodatkowe rundy poprawek. Bezpieczniej oszczędzać na rolach wykonawczych, które już domyślnie używają tańszego modelu.

### Po sprincie zmieniam branch docelowy. Co muszę posprzątać?
Zmienną `MONOLYNX_MR_TARGET` ze środowiska albo z pliku osobistego. W pliku śledzonym nie powinno jej być, więc tam nie ma czego sprzątać.


## Słownik i następny krok


**Słownik**

- **Plik śledzony** - plik zapisany w repozytorium gita, widoczny w każdej kopii roboczej
- **Plik osobisty** - plik ignorowany przez gita, obecny tylko w Twoim katalogu
- **Środowisko procesu** - zmienne dostępne dla uruchomionego programu i programów, które on uruchomi
- **Flagi autonomii** - zmienne `MONOLYNX_AUTO*`, czyli Twoje zgody na samodzielne kroki agenta
- **Worktree** - osobny katalog roboczy tego samego repozytorium, w którym pracuje sesja ticketu
- **Kontrola wstępna** - sprawdzenie konfiguracji na początku ticku dyspozytora


Konfigurację od zera prowadzi wpis [Pierwszy projekt w Monolynx](https://monolynx.com/blog/pierwszy-projekt-w-monolynx). Objawy błędnej konfiguracji i ich naprawę zbiera wpis [Gdy coś nie działa w Monolynx](https://monolynx.com/blog/gdy-cos-nie-dziala-w-monolynx). Wszystkie komendy w jednym miejscu pokazuje [Mapa pluginu Monolynx](https://monolynx.com/blog/mapa-pluginu-monolynx).


**Wezwanie do działania**

Konfiguracja gotowa? Zobacz, jak wygląda sprint prowadzony przez agentów od planu do zamknięcia.

[Przeczytaj przewodnik po sprincie](https://monolynx.com/blog/sprint-z-monolynx-krok-po-kroku)