Instalace AI vývojáře mcptask_runner
Vyberte si operační systém, framework a kódovací CLI — každý příkaz na této stránce se přepíše na ten, který skutečně napíšete.
30 dní zdarma. Bez kreditní karty. Kdykoli zrušíte.
Nejste vývojář? Přepošlete stránku svému týmu
Instalaci provede ten, kdo se u vás stará o projekt a vývojové stroje. Přepošlete mu tuto stránku; pro vás je určen byznysový pohled bez kódu.
Co budete platit
Dvě předplatná, nic dalšího.
mcptask.online
Starter 390 Kč měsíčně za dva uživatele, Professional 300 Kč za uživatele měsíčně. Člověk i runner jsou uživatelé za stejnou cenu: každý runner zabírá vlastní místo, takže vy a jeden runner jste dvě místa.
Programovací CLI
Předplatné platíte přímo jeho poskytovateli – u Claude Code aspoň Pro. Běh bez dozoru spotřebuje víc než ruční práce.
30 dní zdarma, bez platební karty.
Celý ceníkVyberte svůj systém, svůj framework/platformu a své kódovací CLI
Všechno níž je pak psané přesně pro tuhle kombinaci — žádné větvení, které byste museli řešit v hlavě.
Kódovací CLI
Taková dvojice neexistuje, vybraný framework proto zůstal a operační systém se přepnul na macOS.
Co potřebujete před začátkem
Tři věci — a téměř jistě je už máte. Karty i kontroly níže se řídí kódovacím CLI, které jste vybrali nahoře; kontroly navíc jmenují všechny tři hostitele, na kterých runner otevírá pull requesty: GitHub, Bitbucket Cloud a GitLab.
Projekt
Váš projekt musí být git repozitář s originem na GitHubu, Bitbucket Cloudu nebo GitLabu — a musí z něj jít commitovat a otevírat pull requesty ze stroje, kde runner běží. To znamená funkční přístup: ssh klíč, který smí pushovat, právo zápisu do repozitáře a přihlašovací údaj hostitele pro samotný pull request — kontrola PR hostitele níže ukáže, jaký potřebuje ten váš. Runner pracuje pod vaší identitou — co nepushnete vy, nepushne ani on.
Claude Code
Rozjeďte si Claude Code tak, jako byste ho chtěli používat sami: nainstalované, přihlášené a s tarifem, který unese celý pracovní den — alespoň Pro; běh bez dozoru spotřebuje víc než ruční práce. V repozitáři nechte CLAUDE.md — runner si z něj bere kontext o projektu. Kontrola přihlášení je níže.
Codex CLI
Rozjeďte si Codex CLI tak, jako byste ho chtěli používat sami: nainstalované, přihlášené a s tarifem, který unese celý pracovní den; běh bez dozoru spotřebuje víc než ruční práce. V repozitáři nechte CLAUDE.md — runner si z něj bere kontext o projektu a init k němu přidá odkaz v AGENTS.md, aby ho četlo i Codex CLI. Kontrola přihlášení je níže.
OpenCode
Rozjeďte si OpenCode tak, jako byste ho chtěli používat sami: nainstalované, s připojeným poskytovatelem modelů a s tarifem, který unese celý pracovní den; běh bez dozoru spotřebuje víc než ruční práce. V repozitáři nechte CLAUDE.md — runner si z něj bere kontext o projektu. Kontrola poskytovatele je níže.
Účet na mcptask.online
Účet na mcptask.online alespoň s jedním projektem a osobní API token z uživatelského menu. Token autentizuje runner jako vás, aby mohl číst vaše úkoly, zapisovat postup a přidávat zprávy vaším jménem. Bez tokenu není runner — instalační krok se na něj ptá, protože ho instalátor potřebuje pro zapojení vašeho .mcp.json.
Teď si to ověřte, ne předpokládejte
Karty nahoře vysvětlují; tenhle blok kontroluje. Každý příkaz spusťte a porovnejte, co vypíše, s očekávanou odpovědí — pokud se liší, napravte to dřív, než se pustíte do instalátoru.
git a origin na GitHubu, Bitbucket Cloudu nebo GitLabu
Runner otevírá pull requesty, takže váš projekt musí být git repozitář, jehož origin míří na GitHub, Bitbucket Cloud nebo GitLab — u GitLabu to platí pro gitlab.com i pro vlastní instance. Jediný hostitel, kterého runner výslovně odmítá, je GitHub Enterprise: pozná ho podle přesného názvu hostitele a odmítne ho se srozumitelnou zprávou, nikdy ho potichu nepovažuje za github.com.
git remote get-url origingit@bitbucket.org:workspace/vas-projekt.git i git@gitlab.com:skupina/vas-projekt.git jsou stejně dobré odpovědi. SSH alias, mirror nebo self-managed GitLab, který hostitele skryje, je přesně to, na co je init --git-host bitbucket nebo init --git-host gitlab.
Homebrew jen macOS
Instalační kanál pro macOS vede přes Homebrew — na Linuxu nebo Windows tady není co kontrolovat a můžete dál.
brew --versionNa verzi nezáleží — podstatné je, aby se nějaká verze vypsala.
Žádný balíčkovací nástroj navíc Linux a Windows
Instalace na Linuxu a Windows jede rovnou z vestavěného toolchainu — tady není co navíc instalovat ani kontrolovat, pokračujte rovnou instalátorem níže.
Claude Code — nainstalovaný a přihlášený
Všechny ostatní předpoklady na této stránce selžou hlasitě a hned. Tenhle selže zdvořile, o hodiny později, někde, kde se nikdo nedívá: stroj s nainstalovaným, ale nepřihlášeným Claude Code vypadá úplně zdravě. V 08:00 nastartuje naplánovaná úloha, potomek se nedokáže přihlásit a den skončí bez jediného hotového úkolu — jedinou stopou je log, o kterém zatím nevíte, že existuje. Je to nejdražší opomenutí, jaké tahle stránka nabízí, proto dostává nejvíc prostoru. Přihlášení věnujte stejnou pozornost jako instalaci.
Nainstalujte
curl -fsSL https://claude.ai/install.sh | bashmacOS a Linux — na Windows použijte nativní instalátor: irm https://claude.ai/install.ps1 | iex.
Přihlaste se
claudePrvní spuštění otevře přihlášení v prohlížeči. Dokončete ho — teprve další krok potvrdí, že k němu došlo.
Ověřte přihlášení
claude -p "Odpověz přesně jedním slovem: pong"Cokoli jiného než pong — především chyba přihlášení — znamená, že máte opravit přihlášení, ne instalátor.
Codex CLI — nainstalované a přihlášené
Stejné zdvořilé selhání čeká v každém kódovacím CLI: nainstalované, ale nepřihlášené vypadá zdravě, dokud nenastartuje naplánovaná úloha. Codex CLI je to, u kterého runner kontroluje za vás — jeho preflight před každým během spustí codex login status a raději běh odmítne, než aby utratil kvótu za CLI, které selže hned při prvním volání. Spusťte ten příkaz teď, ať k odmítnutí nedojde v 08:00, kdy se nikdo nedívá.
Nainstalujte
npm install -g @openai/codexPotřebuje Node.js; na macOS udělá totéž brew install --cask codex.
Přihlaste se
codex loginOtevře přihlášení v prohlížeči. Dokončete ho — teprve další krok potvrdí, že k němu došlo.
Ověřte přihlášení
codex login statusPřesně ten příkaz, který spouští preflight runneru. Logged in using an API key je stejně dobrá odpověď; Not logged in znamená, že máte opravit přihlášení.
OpenCode — nainstalované a s připojeným providerem
OpenCode mluví s tím poskytovatelem modelů, kterého k němu připojíte, a runner jeho modely jmenuje jako provider/model — samotná instalace je tedy jen polovina. Stroj s nainstalovaným OpenCode bez připojeného providera vypadá stejně zdravě jako nepřihlášený Claude Code a selže stejně zdvořile: o hodiny později, při prvním naplánovaném běhu. Připojte providera teď.
Nainstalujte
curl -fsSL https://opencode.ai/install | bashmacOS a Linux — na Windows použijte npm install -g opencode-ai.
Ověřte instalaci
opencode --versionNa verzi nezáleží — podstatné je, aby se nějaká verze vypsala.
Připojte providera
opencode auth loginVyberte providera, jehož modely pak v konfiguraci runneru uvedete jako provider/model. OpenCode nemá přepínač jen pro čtení a tady ho ani nepotřebuje: runner místo něj vloží mapu oprávnění.
PR hostitel — přihlášený tam, kde se pull request otevírá
Na push větve stačí git. Otevření pull requestu je samostatné volání hostitele, které dělá mcptask_runner pr — jediný příkaz, kterým runner pull requesty otevírá, kontroluje a merguje — a každý hostitel chce vlastní přihlašovací údaj. Zkontrolujte ten, na který míří váš origin.
GitHub
Ověřte, že je gh přihlášené
gh auth statusNa GitHubu jde mcptask_runner pr přes gh a jeho vlastní přihlášení — ssh klíč větev pushne, ale pull request neotevře. Not logged in znamená, že dalším krokem je gh auth login.
Bitbucket Cloud
Dejte údaj do prostředí ještě před init
export BITBUCKET_ACCESS_TOKEN=<your-access-token>Access token (Bearer) pro stroj. Pro člověka místo toho BITBUCKET_EMAIL a BITBUCKET_API_TOKEN (Basic) — nikdy obojí. App passwords se odmítají: Atlassian je ukončil 2026-06-09. V PowerShellu: $env:BITBUCKET_ACCESS_TOKEN = "<your-access-token>".
Co s ním init udělá
ls -l ~/.mcptask_env.d/bitbucket_credentialsinit údaj zapíše do tohoto souboru s právy 0600 — nikdy ho nepřepíše prázdnotou a nikdy ho nevypíše. Na Windows se kontrola práv přeskakuje.
GitLab
Ověřte, že je glab přihlášené
glab auth statusNa GitLabu jde mcptask_runner pr přes CLI glab, které si drží vlastní přihlášení — runner si žádný GitLab credential neukládá. Nepřihlášené glab znamená, že dalším krokem je glab auth login. To, co tam pr create otevře, je merge request.
Self-managed: řekněte to jednou
mcptask_runner init --git-host gitlabSelf-managed instance to potřebuje, protože její origin URL není gitlab.com. Runner po vás URL instance nikdy nechce — glab už ví, kam je přihlášený.
- Kódovací CLI se jmenuje jednou na stroj a projekt: mcptask_runner init --cli claude, codex nebo opencode. Výchozí není žádné — projekt, který žádné neuvedl, runner odmítne jménem, místo aby potichu předpokládal Claude Code.
- launcher.command jen přepíše argv CLI, které jste uvedli; jiné CLI jím podstrčit nejde.
Pak toolchain samotného frameworku
Kontroly výše jsou pro každý projekt stejné. Tyhle stejné nejsou — nahoře si vyberte framework a na stránce zůstane jen jeho blok.
Ruby on Rails
Čtyři odpovědi o stroji a jeden příkaz, který musí doběhnout čistě. První, co runner na Rails projektu udělá, je zavolat binstuby projektu — a ty fungují až ve chvíli, kdy jsou gemy nainstalované.
ruby --versionVerze, kterou pojmenovává .ruby-version projektu, ne ta, kterou přináší operační systém — na nesoulad si bundle install stěžuje jako na první věc.
bundle --versionBundler se instaluje s Ruby, takže obvykle odpoví hned, jak odpoví řádek nad ním.
bin/rails --versionBinstub projektu, ne globální rails: je to verze, se kterou projekt skutečně startuje.
bundle installTohle musí doběhnout čistě dřív, než runner vůbec začne. Nativní rozšíření, které se tady nepodaří přeložit, se nepodaří přeložit ani v žádném běhu bez dozoru — ve tři ráno, kdy se nikdo nedívá.
bin/rails assets:precompile RAILS_ENV=testTento řádek za vás runner nepřidá: je frameworkově neutrální a žádný Rails-specifický příkaz do promptu neposílá. Pokud systémové testy potřebují přeložené CSS, uveďte tento krok v CLAUDE.md nebo v bin/ci svého projektu, jinak budou testy padat.
bin/ci je konvence, ne požadavek. Projekt, který ho má, ho dostane spuštěný; projektu, který ho nemá, se ten krok přeskočí. Rails projekty ho obvykle mají, takže tohle je framework, kde ho runner najde nejčastěji.
Ruby on Rails je jediný framework, který mění instalační kanál — wrapper gem místo Homebrew, curlu nebo scoopu. To patří na další obrazovku; tady s tím není co dělat.
Django (Python)
Python 3, virtualenv, který je opravdu aktivní, a django-admin, který odpovídá zevnitř. Prostřední bod je místo, kde se to láme: instalace do systémového Pythonu vypadá, že prošla, a pak ve chvíli, kdy runner zavolá, není k nalezení.
python3 --versionPod jménem python3 — na stroji, kde python pořád ukazuje na 2.x, je to jediné jméno, které odpovídá spolehlivě.
source .venv/bin/activate && which pythonCesta musí vést dovnitř projektu. Když se vypíše /usr/bin/python, virtualenv aktivní není a všechno níž se nainstaluje do systémového Pythonu.
django-admin --versionSpusťte s aktivním virtualenvem. Verze vypsaná z globální instalace není ta, se kterou projekt běží.
bin/ci je konvence, ne požadavek. Django projekty ho obvykle nemají a je to v pořádku — runner ten krok přeskočí, místo aby na něm spadl. Není tu žádný soubor, který byste měli dopsat.
Laravel (PHP)
PHP, Composer a artisan. Všechny tři odpoví během vteřiny a třetí navíc dokazuje, že stojíte v kořeni projektu — artisan je soubor v projektu, ne příkaz v PATH.
php --versionVerze, kterou si žádá composer.json projektu — Laravel 11 chce 8.2 nebo novější.
composer --versionComposer instaluje závislosti projektu stejně, jako to pro Ruby dělá bundler, takže ho runner potřebuje dřív, než může cokoli spustit.
php artisan --versionSpouštějte z kořene projektu. Když se nevypíše nic, je to obvykle špatný adresář, ne chybějící Laravel.
bin/ci je konvence, ne požadavek. Laravel projekty ho obvykle nemají a runner ten krok jednoduše přeskočí — nechybí vám soubor, který jste měli napsat.
Node.js
Runner spouští vlastní npm skripty projektu, takže odpovědět musí dvě věci: samotný Node a package manager, který pojmenovává lockfile.
node --versionStačí jakékoli aktuální LTS — kontroluje se, že se verze vůbec vypíše.
ls package-lock.json pnpm-lock.yaml yarn.lock 2>/dev/nullLockfile, který se vypíše, pojmenovává package manager projektu: package-lock.json je npm (instaluje se s Nodem), pnpm-lock.yaml je pnpm, yarn.lock je yarn. Nainstalujte právě ten — špatný tip je tady první matoucí chyba.
Node.js projekt dostane na další obrazovce druhý instalační kanál: npx @mcptask/cli init — npm wrapper. OS kanál výše pořád funguje; výběr mezi nimi patří další obrazovce.
React
React běží na Nodu, takže toolchain je stejný, jaký kontroluje obyčejný Node.js projekt — stejný Node, stejný package manager, nic navíc se neinstaluje. Jediný poctivý rozdíl je vstupní bod, který projekt sám deklaruje pro develop a test.
node --versionStačí jakékoli aktuální LTS — kontroluje se, že se verze vůbec vypíše.
ls package-lock.json pnpm-lock.yaml yarn.lock 2>/dev/nullStejné jako u Node.js — lockfile, který se vypíše, pojmenovává package manager, který se má nainstalovat.
node -p "Object.keys(require('./package.json').scripts)"Tohle jsou příkazy, které runner nakonec zavolá — dev server a test vstup vycházejí z tohoto seznamu, takže v něm dev a test musí být.
React projekt dostane na další obrazovce stejný npm kanál jako Node.js projekt: npx @mcptask/cli init.
Java
JDK a build tool, který projekt nese s sebou — Gradle nebo Maven rozhoduje projekt, ne vy, a ten špatný padne na prvním spuštění.
java -versionVerze se vypisuje na stderr, takže se ukáže tak jako tak — kontroluje se, že vůbec odpovědělo JDK.
ls build.gradle build.gradle.kts pom.xml 2>/dev/nullSoubor, který se vypíše, pojmenovává build tool: soubor Gradle znamená Gradle, pom.xml znamená Maven.
./gradlew --versionPoužijte wrapper projektu, ne systémovou instalaci — nese ho každý Gradle projekt a fixuje verzi, se kterou se projekt builduje. Maven projekt řekne místo toho ./mvnw --version.
Android
Android je Java projekt plus build toolchain: JDK, pak Gradle, pak Android SDK — a pokud jsou testy projektu instrumentation testy, musí být dosažitelné i zařízení nebo emulátor.
java -versionGradle běží na JDK, takže tahle odpověď otevírá všechno pod ní.
./gradlew --versionKaždý Android build jde přes Gradle — na rozdíl od obyčejného Java projektu tu žádná Maven varianta k detekci není.
adb --versionadb je součást platform-tools SDK, takže vypsaná verze dokazuje, že SDK je nainstalované.
adb devicesStačí jeden vypsaný emulátor nebo zařízení — záleží na tom jen tehdy, když projekt spouští instrumentation testy, a nic jiného na téhle stránce si chybějícího nevšimne.
Runner řídí jakékoli CLI, kterým projekt builduje a testuje, takže projekt, jehož testy potřebují zařízení nebo emulátor, ho musí mít dostupné v době běhu — včetně naplánovaného běhu ve 03:00.
Swift / Xcode jen macOS
Samotné Xcode, jeho command line tools a xcodebuild — všechny tři existují jen na macOS, proto vám picker tenhle framework nikde jinde nenabídl.
xcode-select -pCesta k nástrojům příkazové řádky. Dokud Xcode není nainstalované, stačí i odpověď /Library/Developer/CommandLineTools, pro další krok už ale Xcode nainstalované být musí.
xcodebuild -versionJedna odpověď za Xcode i jeho ovladač xcodebuild — a verze musí být ta, se kterou projekt builduje, ne nejnovější, kterou App Store nabízí.
xcrun simctl list devices available | grep -c iPhoneCokoli nad nulu stačí — záleží na tom jen tehdy, když testy projektu startují simulátor.
Runner řídí jakékoli CLI, kterým projekt builduje a testuje — tady xcodebuild — takže projekt, jehož testy běží na simulátoru, ho potřebuje dostupný v době běhu, ne jen při instalaci.
Bez frameworku
Nic nad rámec kontrol výše. To je celá odpověď, ne blok, který se nenačetl: projekt stavěný Makefilem, shellovým skriptem nebo ničím nemá žádný frameworkový toolchain ke kontrole, takže git s originem na GitHubu, Bitbucket Cloudu nebo GitLabu a přihlášené kódovací CLI jsou celý seznam.
bin/ci je konvence, ne požadavek. Když ho projekt má, runner ho spustí; když ne, ten krok se přeskočí. Nic k instalaci, nic k psaní — pokračujte na další obrazovku.
Nainstalujte runner a spusťte init
Dva kroky: A) runner na tenhle stroj, B) init, který v projektu založí všechno ostatní — token, MCP záznam (u Claude Code v .mcp.json), sekci v CLAUDE.md, skills i naplánovaný běh. Init se na API token zeptá; najdete ho na mcptask.online → vaše jméno (vpravo nahoře) → Zobrazit → Rozšířené informace → API Token. Ručně nepíšete nic; komu se binárka nehodí, má postup bez ní dole na stránce.
Nainstalujte runner
Jeden příkaz, který za vás vybralo to, co jste zvolili nahoře. Šest frameworků dostane správce balíčků svého operačního systému, Ruby on Rails místo něj wrapper gem a Node.js s Reactem k němu navíc npm.
Binárka zatím není podepsaná ani notarizovaná u Applu, a proto k ní Gatekeeper po stažení připne atribut com.apple.quarantine. Cask ho smaže; bez toho by první spuštění skončilo bez jakéhokoli výpisu a vypadalo jako rozbitá binárka. Pravost stažení si ověříte kontrolním součtem SHA-256 proti checksums.txt z vydání, postup je níže.
Skript čte čtyři proměnné, pokud je nastavíte: MCPTASK_VERSION přišpendlí konkrétní release tag, MCPTASK_INSTALL_DIR změní cíl, MCPTASK_RELEASE_REPO ho pošle na fork a GITHUB_TOKEN zvedne anonymní rate limit. Sudo nevolá nikdy.
Bucket se přidává jen jednou; druhá instalace na stejném stroji je samotný druhý příkaz.
Rails projekt runner z operačního systému neinstaluje vůbec. Wrapper gem ten kanál celý nahrazuje — binárka přijde stejným Gemfilem, kterým prochází i zbytek projektu.
group :development do gem "mcptask-rails-runner" end
Proč přes Gemfile: verzi pak drží lockfile, který váš tým už tak jako tak prochází v pull requestu, takže na nový runner přejde celý tým společně a vědomě — místo aby to bylo po jednom stroji vždycky, když někdo náhodou pustí upgrade. Gem je na rubygems pod vlastním jménem mcptask-rails-runner — není to starý gem ze zdroje na GitHubu v nové verzi.
Node.js a React dostanou jeden kanál navíc, ne jiný: npx je přirozená cesta, jak se z JS projektu dostat k nástroji, a příkaz operačního systému nahoře platí dál.
Balíček žádnou binárku nenese. Jeho postinstall stáhne ze stejného mirroru archiv pro vaši platformu, ověří SHA-256 proti checksums.txt a rozbalí ho do lokálního bin adresáře; wrapper pak beze změny předává argumenty i návratové kódy, takže se chová jako binárka sama. Publikuje se přes OIDC trusted publishing, takže nikde neleží dlouhodobý npm token, který by mohl uniknout.
Ať už kanál, jaký chce: stejných šest release archivů na tag — darwin/amd64, darwin/arm64, linux/amd64, linux/arm64, windows/amd64, windows/arm64 — a stejné ověření SHA-256 proti stejnému checksums.txt předtím, než se cokoli rozbalí. Neexistuje zvláštní „windowsový řetězec důvěry“, který by byl slabší nebo silnější než ostatní.
Spusťte init s volbami, které chcete
Jeden příkaz nainstaluje runner do tohoto projektu. Vypsaný s volbami, ne holý — protože právě volby rozhodují, kam půjdou automaticky založené chyby, jaký režim naplánovaná úloha spouští a kdy.
Kteroukoli z nich vynechte a init se zeptá — je to především interaktivní instalátor. Co ale neudělá, je hádat: --cli nemá výchozí hodnotu, takže projekt, který své kódovací CLI nikdy neuvedl, se odmítne jménem, místo aby se předpokládal Claude Code; a neinteraktivní instalace (roura, provisioning skript, na druhém konci žádný terminál) bez --mode plánování úplně přeskočí, místo aby režim zvolila za vás. --at má výchozí hodnotu 08:00. --until nemá výchozí hodnotu žádnou: když ji vynecháte, konec dne prostě není a runner pracuje, dokud nevyčerpá kvótu.
Dalších sedm voleb
- --git-host HOSTITEL
- Pevně určí PR hostitele — github, bitbucket nebo gitlab — když se to z URL originu vyčíst nedá: SSH alias, mirror, self-managed GitLab. Bez ní se odvodí z git remote get-url origin. GitHub Enterprise se odmítne jménem.
- --schedule
- Přegeneruje naplánovanou úlohu a nic víc — skills, oprávnění, token a sekce v configu zůstanou přesně tak, jak jsou.
- --force
- Přepíše to, co na tomto stroji už je: skills, sekce configu a naplánovanou úlohu.
- --helper-bin-dir CESTA
- Kam se zapíšou pomocné skripty pro CI a testy. Výchozí ~/.claude/bin.
- --home-dir CESTA
- Přesměruje adresář s tokenem, rc soubor shellu a naplánovanou úlohu. Výchozí je vlastní domovský adresář uživatele.
- --verbose
- Vypisuje každý řádek streamu místo filtrovaného pohledu. Sedí na kořenovém příkazu, takže platí pro každý podpříkaz.
- --ignore-quota
- Přeskočí každou kontrolu kvóty. Také volba kořenového příkazu.
Tři z nich jsou to, čím je tenhle příkaz použitelný z provisioning skriptu: --force, aby opakované spuštění nebyla otázka, a --helper-bin-dir s --home-dir, aby build agent mohl psát jinam než do domovského adresáře skutečného uživatele.
Co init nechal na disku
Ne aby vás to uklidnilo — abyste to našli. Init můžete kdykoliv spustit znovu: každý krok je idempotentní a co jste upravili ručně, zůstane.
Skills zkopírované pro vaše CLI — dvanáct u Claude Code, devět u Codex CLI a OpenCode
Claude Code dostane dvanáct do .claude/skills/: ci-runner, ci-start, ci-wait, wait-unlock, test-runner, test-start, test-wait, discover, memory-search, mcptask-read, mcptask-write a pr. Codex CLI dostane devět do .agents/skills/ a OpenCode devět do .claude/skills/ — stejný seznam bez discover, memory-search a mcptask-read, které forkují subagenta, jakého umí spustit jen Claude Code. Ke každé se do .mcptask_runner_manifest.json zapíše MD5 hash obsahu, aby pozdější mcptask_runner update poznal dodaný soubor od toho, který jste upravili.
Přibude jediný MCP záznam — nic dalšího
Přidá se pouze server mcptask-online proti https://mcptask.online/mcp, který čte proměnnou s vaším tokenem — do .mcp.json u Claude Code, do .codex/config.toml u Codex CLI, do opencode.json u OpenCode. Všechny ostatní MCP servery v tom souboru zůstanou přesně tak, jak byly. U Claude Code je záznam "type": "http": stroj, který už na něm je, se nikdy nedegraduje zpět na SSE, a .mcp.json, který nelze naparsovat, se odmítne místo přepsání — --force ho nejdřív odsune do .mcp.json.bak.
Token exportován pod názvem, který deklaruje vaše MCP konfigurace
Token se uloží pod názvem proměnné, který deklaruje MCP konfigurace vašeho projektu — ne pod natvrdo daným MCPTASK_TOKEN. Na Unixu se zapíše do ~/.mcptask_env.d/ a ~/.zshenv (v bashi ~/.bash_profile a ~/.bashrc) se naučí tento adresář sourcovat; na Windows se uloží přes setx. Stejnou cestou jde údaj pro Bitbucket, do ~/.mcptask_env.d/bitbucket_credentials s právy 0600 — nikdy se nepřepíše prázdnotou, nikdy se nevypíše; na Windows se tahle kontrola práv přeskakuje. Na token, který se už podaří vyhodnotit, se instalátor podruhé neptá.
Oprávnění nastavená pro vaše CLI, jen přidáváním
U Claude Code se baseline oprávnění slučují do .claude/settings.local.json striktně aditivně: allow a deny se sjednotí s tím, co už tam je, enableAllProjectMcpServers se jen zapíná, a všechny ostatní klíče v souboru zůstanou nedotčené. Nic, co jste ručně povolili nebo zakázali, se neztratí. Tahle oprávnění Claude Code platí jen pro Claude Code: Codex CLI se řídí souborem .codex/config.toml, který init zapsal, a OpenCode souborem opencode.json s mapou oprávnění, kterou runner vloží, protože OpenCode nemá přepínač jen pro čtení.
Vygenerován plánovaný běh, zapsány helpery a konfigurace
Plán se vygeneruje pro OS, na kterém jste — launchd LaunchAgent, systemd user timer, nebo Task Scheduler XML — aby spouštěl ~/.mcptask/bin/mcptask_runner ve všední dny v čase, který jste zvolili; příkaz k jeho aktivaci se vytiskne, abyste ho spustili. Vedle toho se do ~/.claude/bin uloží devět helper skriptů (ci_start, ci_wait, _ci_filter_tail, test_start, test_lock, check_test_lock, run_with_log, kill_tree a runner-log, kterým se čte log běžícího runneru) a do config/mcptask_runner.yml se zapíše cíl pro bugy a strategie čekání.
Naplánovaná úloha se vygeneruje, ale neaktivuje. Init zapíše LaunchAgent, systemd user timer nebo XML pro Task Scheduler, vypíše ten jeden příkaz, který ji zapne — a tím skončí. Nic neutratí ani kousek kvóty, dokud ten příkaz nespustí člověk, o dvě obrazovky níž.
Nejdřív se podívejte, nic se nezmění
once_dry je jediný režim, který úplně přeskočí triage: ukáže další úkol a skončí. Žádná větev, žádný commit, žádná kvóta — odpovídá na jedinou otázku, kterou teď máte: je token správně a vidí runner váš projekt?
Prázdná fronta je naprosto dobrý výsledek. Testujete spojení, nehledáte práci — něco přiřadíte později, až to bude mít smysl.
Pak jeden úkol, vybraný vámi
Pořád bez rizika. --task-id osloví jednu konkrétní položku přímo, místo aby procházel frontu — takže nezáleží na tom, komu je úkol přiřazený. Namiřte runner na libovolný úkol; v praxi si udělejte zkušební a sledujte, co se stane.
--task-id je povinné pro task_manual a task_auto_squash — bez něj se režim odmítne.
Na příkazové řádce fungují i task, story a queue: jsou to aliasy pro task_manual, story_manual a queue_manual, takže nikdo nemusí hádat, která podoba je správná.
Jak vypadá „hotovo“: větev, commity a pull request nechaný otevřený k revizi — otevřený přes mcptask_runner pr u toho hostitele, na kterého míří origin — GitHubu, Bitbucket Cloudu nebo GitLabu. task_manual je manuální režim — nic se nemerguje; mergují až varianty auto-squash, po zeleném CI. Úplná tabulka režimů je na stránce Runner: Loop + goal
Toto je první příkaz na stránce, který utrácí skutečnou kvótu. Když už je denní kvóta vyčerpaná, --ignore-quota kontrolu přeskočí — přijetí znamená, že runner pracuje za hranicí, vědomě a na váš pokyn.
Nyní doopravdy: úloha na rozvrhu
Povolte naplánovanou úlohu, jednou ji spusťte ručně a sledujte log. Toto je první obrazovka, na které runner běží bez vás.
<slug> je basename adresáře projektu s podtržítky nahrazenými pomlčkami — objevuje se v labelu plistu, v názvech systemd jednotek, v názvu Windows úlohy, ve wrapper skriptu i v názvu logu, takže zástupný text čtete všude stejně.
Příklad, protože samotný zástupný text se snadno přečte špatně: projekt leží v ~/Projects/my_shop, basename je tedy my_shop, podtržítko se změní na pomlčku a slug je my-shop. Každý řádek na této obrazovce čtěte s my-shop všude, kde stojí <slug>:
Tento příklad je jen informativní — ručně nic skládat nemusíte. mcptask_runner init na konci vypíše hotové příkazy pro váš projekt, slug už doplněný a barevně zvýrazněný, připravené ke zkopírování. Obrazovky tady jsou proto, abyste poznali, co vám init vypsal, a věděli, jak úlohu zase vypnout.
Naplánovaná úloha nikdy nenačítá váš shell profil. Token se čte z proměnné, kterou deklaruje .mcp.json (výchozí MCPTASK_TOKEN), a v době instalace se vloží přímo do úlohy. Když se nic nevyhodnotí, zapíše se doslova řetězec SET_MCPTASK_TOKEN_HERE a runner odmítne nastartovat, místo aby běžel jako nobody.
Webové rozhraní, od zítřka dál
Než runner začne sám vybírat práci, musí se v prohlížeči stát dvě věci: zapnout zobrazení runneru a přiřadit tickety uživateli, jehož API token je v .mcp.json. První zpřístupní grid, druhé naplní frontu.
Dosud jste runner zkoušeli z terminálu: volný pohled, jeden úkol podle id a pak běh bez dozoru. Webové rozhraní k tomu potřeba nebylo a nic se nemuselo přiřazovat, protože --task-id oslovuje úkol přímo. Tady přecházíte od „chci vidět, co to dělá“ k „takto to budu používat“.
Zapněte zobrazení runneru
Mřížka runnerů se na domovské stránce zapíná zvlášť pro každého uživatele. Bez něj se sekce na domovské stránce prostě nezobrazí a runner vypadá, jako by tam nebyl, i když je připojený a čeká.
Otevřete Uživatelé, pak Upravit u uživatele, pod kterým se runner autentizuje.
Na kartě Elementy na úvodní stránce zaškrtněte v sekci Zobrazit volbu „Aktivita runnerů“.
Uložte. Runner grid se na domovské stránce daného uživatele objeví — prázdný, dokud se něco nepřipojí.
Grid je prázdný záměrně. Uvnitř se nic nevykreslí, dokud se runner skutečně nepřipojí; „žádná karta“ na čerstvé instalaci je očekávaný stav, ne porucha.
Přiřaďte práci uživateli, pod kterým se runner autentizuje
Fronta nabízí výhradně přiřazenou práci. Nepřiřazený ticket je pro @next neviditelný — ne méně prioritní, neviditelný. Od této chvíle runner vybírá práci sám a může vybrat jen to, co mu bylo předáno, takže assignee ticketu musí být uživatel, jehož API token je v .mcp.json.
Řeč je o uživateli, jehož token je v .mcp.json — ne nutně o čtenáři, a na sdíleném stroji to bývá často někdo jiný. Když přiřadíte práci sobě, ale runner drží token kolegy, výsledkem je runner, který sedí a nemá co dělat.
Jen přiřazené, ne méně prioritní
Neexistuje „nízká priorita pro nepřiřazené“. Fronta je plochý seznam ticketů přiřazených runnerovu uživateli; zbytek se v ní vůbec neobjeví. Dodatečné přiřazení je oprava, ne změna priority.
Tři věci, které runner nevezme
Každá z nich při prvním kontaktu vypadá jako rozbitá instalace, protože ticket existuje, je otevřený a nic se neděje. Společné vlákno: runner ticket pozná, ale považuje ho za nedozrálý. Fronta dělá, co jí bylo řečeno.
Typ ticketu: ideaIdeas runner nikdy nenabídne. Fronta runneru jsou pouze tasky, stories a recurenty — idea se musí nejdřív povýšit na task, aby ji runner mohl vzít.
Story bez subtaskůStory, která nemá žádné tasky pod sebou, runner nikdy nenabídne. Otevřete story, přidejte aspoň jeden task a runner ji uvidí. Story s jedním subtaskem je story s jedním ticketem; to je nejmenší jednotka, kterou fronta odešle.
Přiřazení StoryKdyž runnerovu uživateli přiřadíte story, fronta se uzavře: její subtasky opustí obecnou frontu a runner jde touto story. Účelné (jedna story, jeden PR, jeden squash), překvapivé, pokud jste čekali, že se to bude chovat jako task. Když chcete, aby fronta tekla dál, přiřazujte task, ne story.
Nakrmte ho něčím, co stojí za to dělat
Runner je jen tak dobrý, jako ticket, který dostane. První běh bez dozoru nad vágními tickety — otevřená kritéria přijetí, nedefinované „hotovo“, úkol, jehož název tvoří celá funkce — naučí špatnou lekci o produktu, protože runner udělal přesně to, co ticket říkal, a co říkal, nebylo nic užitečného. Napište další task tak, jako byste první den instruovali nováčka.
Sledujte runner při práci: živá karta
Jediná obrazovka na této stránce, která je obrázek — protože smysl má jen karta v pohybu. Všechno výše jste psali vy; tohle je runner, který odpovídá.

Co očekávat v čase
Mezera mezi spuštěním runneru a zobrazením karty je přesně tam, kde většina lidí usoudí, že je něco rozbité. Není — karta má vlastní životní cyklus a vypadá takto:
Karta se objeví během pár sekund po startu runneru. Když je zobrazení runnerů zapnuté a mřížka viditelná, nic víc není potřeba.
Podle průběhu běhu prochází stavy starting → triage → processing — stavový automat otevřeně, ne schovaný za spinnerem.
Když smyčka skončí, dokončená karta ještě 60 sekund zůstane a pak zmizí. Karta, která mizí, je runner, který doběhl — ne rozbitá mřížka.
Runner spuštěný bez tokenu to řekne — jednou, nahlas, při startu. Neselže potichu tím, že na mřížce prostě chybí.
Prázdná mřížka znamená jednu ze dvou věcí
Buď runner ještě neběží — zkontrolujte obrazovku s plánovačem výše — nebo nastartoval, ale nemohl se připojit, což by při startu řekl. Rozhodně to neznamená, že instalace selhala: dokončená instalace má mřížku na domovské stránce, ať už právě něco běží, nebo ne.
Zapojte to ručně — bez binárky
Libovolný MCP-kompatibilní AI klient umí mluvit s mcptask.online přímo. Čtyři kroky, všechny jen konfigurace: získat token, deklarovat server, nasměrovat agenta na projekt, ověřit.
Získejte svůj API token
Přihlaste se na mcptask.online, otevřete vaše jméno (vpravo nahoře) → Zobrazit → Rozšířené informace → API Token. Zkopírujte řetězec přesně tak, jak je zobrazen — je to neprůhledné tajemství bez pevného prefixu i délky, takže ho nikdy nepřepisujte z hlavy. Zacházejte s ním jako s heslem: kdokoli ho má, jedná za vás na mcptask.online.
mcptask.online → vaše jméno (vpravo nahoře) → Zobrazit → Rozšířené informace → API Tokenexport MCPTASK_TOKEN='<sem vložte svůj API token>'Název proměnné je na vás — nic na naší straně ho nefixuje. Podstatné je, aby název, který zde exportujete, byl přesně ten, který váš .mcp.json dosazuje v kroku 2. Když se ty dva rozejdou — exportujete MCPTASK_KAMR_TOKEN, ale konfigurace stále čte ${MCPTASK_TOKEN} — klient dosadí to, co náhodou obsahuje ta druhá proměnná, nebo prázdný řetězec. V prvním případě se agent přihlásí jako jiný uživatel a práce skončí na cizím dashboardu; ve druhém je prostě odmítnut.
Co se právě stalo
Přidejte řádek s exportem do svého shell profilu, aby token viděl každý MCP klient, kterého spustíte — a zapište ho do souboru, který čte i login shell. Token jen v ~/.zshrc nebo ~/.bashrc tam je, když otevřete terminál, a chybí, když stejnou práci spustí launchd nebo systemd user timer; soubor, který přežije obojí, je ~/.zprofile (na Linuxu ~/.bash_profile nebo ~/.profile). Na Windows platí $env:MCPTASK_TOKEN jen po dobu otevřeného okna — do uživatelského prostředí, ze kterého čte Plánovač úloh, ho zapíše až setx, nebo SetEnvironmentVariable se scope User.
Deklarujte server mcptask-online ve své MCP konfiguraci
Otevřete MCP konfigurační soubor vašeho klienta — .mcp.json v kořeni projektu pro Claude Code, nebo developer nastavení Claude Desktopu — a přidejte záznam níže. Hlavička Authorization dosazuje přesně tu proměnnou, kterou jste exportovali v kroku 1, takže je přejmenujte obě, nebo ani jednu.
{
"mcpServers": {
"mcptask-online": {
"type": "http",
"url": "https://mcptask.online/mcp",
"headers": {
"Authorization": "Bearer ${MCPTASK_TOKEN}"
}
}
}
}
Nové konfigurace pište jako "type": "http" proti https://mcptask.online/mcp. Starší konfigurace používají "type": "sse" proti https://mcptask.online/mcp/sse — server tento zápis stále přijímá, takže existující SSE záznam dál funguje, ale je to zastaralá forma. Pro Claude Desktop vložte stejný záznam do jeho vlastního MCP konfiguračního souboru claude_desktop_config.json — otevřete ho z nastavení Claude Desktopu, ne z cesty, kterou bychom sem vypsali, protože umístění souboru i pojmenování té obrazovky se liší podle OS a verze.
Řekněte agentovi, na kterém projektu má pracovat
Otevřete CLAUDE.md svého projektu (nebo ekvivalentní kontextový soubor, který váš AI klient čte) a přidejte sekci níže. Bez ní agent neví, který projekt a účet má číst a zapisovat — je to lidsky čitelný způsob, jak získá orientaci. Vzor níže je na stránce jediný, druhá varianta neexistuje; řádek s pracovní smyčkou v něm nechte, je to on, co drží agenta v běhu — bez něj skončí po jednom úkolu.
## mcptask.online
- Project name: <your project name>
- project_relative_id=<your project id>
- account_code: `<your account code>`
## Usage notes
- Access mcptask.online via the MCP server (key: `mcptask-online`).
- Everything is a **piece** — URIs never use `/tasks/` or `/stories/`.
- Always use `relative_id` in URLs / references, never the internal `id`.
- Read with: mcptask://pieces/{account_code}/{piece_id}
- Current user: mcptask://user (a literal URI — it takes no account code)
- Create pieces via the write tools; **content in English**.
- The work loop: load the most important task → work on it → check the daily quota → repeat.
Co se právě stalo
project_relative_id a account_code si přečtěte z obrazovky, neodhadujte je podle názvu projektu: project_relative_id je číslo v URL, když projekt na mcptask.online otevřete, a account_code je krátký kód pod názvem účtu v přepínači účtů. Bez těch dvou hodnot runner odmítne nastartovat. Není to varování, které vypíše a jede dál — nemá účet, kterého by se zeptal, ani projekt, na který by se ptal, takže skončí.
Ověřte spojení
Restartujte svého AI klienta (nebo znovu načtěte jeho MCP config). Položte agentovi jednu lidskou otázku, abyste ověřili, že se na mcptask.online dostane. Pokud vrátí piece, jste připojeni. Pokud vyhodí chybu, skočte do FAQ níže.
Vypiš mi další otevřený úkol z mého mcptask.online projektu.mcptask://pieces/{account_code}/@next?project_relative_id={project_relative_id}&exclude_relative_ids={exclude_relative_ids}Co se právě stalo
Toto URI je kanonický vstupní bod pro čtení. Query parametr project_relative_id k němu patří — discovery URI je celý ten řetězec, ne jen část před otazníkem. Pokud ho agent umí načíst a vrátí jeden úkol, fungují i všechna ostatní piece URI.
Jak ověřit, že to funguje
Tři rychlé kontroly, v pořadí za sebou. Pokud všechny tři projdou, spojení je v pořádku. Pokud některá selže, FAQ níže uvádí nejčastější příčinu.
Agent vypíše vaše projekty
Požádejte agenta, aby vypsal vaše projekty. Měl by vrátit alespoň jeden řádek s názvem projektu a project_relative_id. Pokud nevrátí nic, token je špatně nebo v CLAUDE.md chybí account_code.
Jaké projekty mám na mcptask.online?Agent načte další otevřený úkol
Požádejte o další úkol. Měl by vrátit jeden piece s názvem, popisem a obtížností (pole scrum_point). Pokud nemáte žádné otevřené úkoly, nevrátí žádný piece, ale krátkou zprávu, že není co dělat — přesné znění posílá server a může se lišit. I tak je to v pořádku, spojení funguje.
Načti mi další otevřený úkol.Agent umí přečíst konkrétní úkol podle URI
Dejte mu přesné URI z webového UI (otevřete libovolný úkol, zkopírujte relative_id z URL). Agent by měl vrátit plné detaily tohoto úkolu. Toto je nejspolehlivější kontrola celého řetězce.
Přečti mcptask://pieces/{account_code}/{piece_id} a shrň mi to.Časté otázky, srozumitelně
Co je MCP, lidsky řečeno?
Představte si MCP jako USB kabel mezi vaším kódovacím CLI a mcptask.online — runner připojí Claude Code, Codex CLI nebo OpenCode k vaší frontě úkolů, takže AI může přímo číst, pracovat a logovat úkoly. Samotná zkratka je jednou definovaná ve slovníčku na stránce Integrace pro vývojáře.
Funguje to i na Linuxu / Windows / serveru?
Ano — runner, .mcp.json a skills běží na každém desktopovém OS. Plánování má tři reálné back-endy, ne jen macOS: launchd LaunchAgent na macOS, systemd user timer na Linuxu a Task Scheduler na Windows. Na jakémkoliv jiném systému init vypíše Scheduling: skipped (no generator for ...) místo toho, aby hádal, a instalace doběhne bez plánu. Na serveru, kde nikdo není přihlášený, systemd user timer sám nepoběží; init proto na Linuxu vypíše příkaz sudo loginctl enable-linger $USER, který ho pustí i bez přihlášení. Jiný plánovač, třeba cron, runner nevytváří. Cesty k souborům a příkazy pro zapnutí najdete v obrazovce s během na pozadí výše.
Je bezpečné nechat runner běžet bez dozoru?
Ano, pokud víte, co který režim smí. Runner běží na vašem stroji s vaším vývojovým prostředím a vývojovou databází, takže testuje, dělá screenshoty a pushuje commity jako vývojář; produkční data vidí jen tehdy, když mu k nim sami dáte přístup. Slučuje pouze v režimech *_auto_squash, a to až po projití lokálních testů a CI; projekt bez CI sloučí po lokálních testech. Ruční režimy, například queue_manual nebo task_manual, nesloučí nikdy a jen otevřou PR ke kontrole. Když se agent zasekne, dojde mu kontext nebo ho něco přeruší, harness se zotaví a úkol skončí v PR, nezůstane rozdělaný. Narazí-li runner na cizí chybu, založí na ni vlastní sledovaný úkol a zpracuje ho ve stejném režimu jako vaši práci.
Mohu instalaci vrátit zpět?
Ano, ale ručně — odinstalační příkaz runner nemá. Tohle všechno init zapíše:
V projektu smažte skills — u Claude Code dvanáct v .claude/skills/: ci-runner, ci-start, ci-wait, wait-unlock, test-runner, test-start, test-wait, discover, memory-search, mcptask-read, mcptask-write a pr; u Codex CLI (.agents/skills/) a OpenCode (.claude/skills/) jejich devět bez discover, memory-search a mcptask-read. Dále .mcptask_runner_manifest.json, .claude/test-commands.json, záznam mcptask-online v .mcp.json, .codex/config.toml nebo opencode.json, oprávnění runneru v .claude/settings.local.json a config/mcptask_runner.yml i s jeho řádkem v .gitignore.
V domovském adresáři smažte helper skripty a spouštěč mcptask-runner-<slug> v ~/.claude/bin, adresář ~/.mcptask_env.d/ a řádek, který ho načítá, z ~/.zshenv (u bashe z ~/.bash_profile a ~/.bashrc; na Windows proměnnou nastavenou přes setx).
Naplánovanou úlohu zrušíte na macOS příkazem launchctl bootout gui/$(id -u)/online.mcptask.runner-<slug> a smazáním ~/Library/LaunchAgents/online.mcptask.runner-<slug>.plist, na Linuxu příkazem systemctl --user disable --now mcptask-runner-<slug>.timer a smazáním .service a .timer v ~/.config/systemd/user/, na Windows příkazem schtasks /Delete /TN mcptask-runner-<slug> a smazáním ~/.mcptask/mcptask-runner-<slug>.xml.
Binárka odejde týmž kanálem, kterým přišla: ručně u install scriptu, brew uninstall jchsoft/tap/mcptask_runner u Homebrew, scoop uninstall mcptask_runner u Scoopu; npx globálně nic neinstaluje; u Rails wrapper gemu odeberte řádek mcptask-rails-runner z Gemfile a smažte ~/.mcptask/bin.
Vezměte si token a spusťte instalátor
Založte si účet na 30 dní zdarma a získejte MCPTASK_TOKEN. Pak spustíte instalátor a runner si vyzvedne váš nejdůležitější úkol.
30 dní zdarma. Bez kreditní karty. Kdykoli zrušíte.