Codex CLI 0.115.0: Naprawiono błąd wyświetlania narzędzi serwera MCP

Nieduża zmiana, a jednak kluczowa dla codziennej pracy. W wydaniu Codex CLI 0.115.0, które skupiało się na dużych funkcjach, takich jak zaawansowana inspekcja wizualna, znalazła się też drobna, ale ważna poprawka. Rozwiązuje ona irytujący problem: polecenie /mcp nie wyświetlało dostępnych narzędzi dla serwerów MCP, które w swojej nazwie miały myślniki. Dla deweloperów korzystających z takich konfiguracji to istotne udogodnienie, które eliminuje niepotrzebne godziny szukania przyczyny błędu.

Ten błąd mógł wprowadzać w błąd, sugerując, że serwer jest bezużyteczny, podczas gdy on po prostu nie potrafił się poprawnie przedstawić. W świecie lekkich agentów kodujących (lightweight coding agents), gdzie każda sekunda w terminalu ma znaczenie, takie usterki potrafią solidnie pokrzyżować plany.

Na czym dokładnie polegał problem?

Sprawa dotyczyła komendy /mcp, która w Codex CLI służy do wyświetlania statusu i listy dostępnych narzędzi podłączonych serwerów MCP. MCP (Model Context Protocol) to kluczowy komponent pozwalający Codexowi na integrację z zewnętrznymi narzędziami, pluginami czy nawet innymi agentami AI.

Codex od zawsze akceptował nazwy serwerów MCP zawierające myślniki. Spełniały one wyrażenie regularne ^[a-zA-Z0-9_-]+$. Problem pojawiał się później, gdy użytkownik chciał sprawdzić możliwości takiego serwera. Mimo że serwer działał poprawnie i oferował swoje funkcje, polecenie /mcp wyświetlało przy nim po prostu: Tools: (none).

To tak, jakbyście podłączyli nową wiertarkę do gniazdka – światełko się pali, ale gdy próbujecie sprawdzić jej moc, kontrolka pokazuje „brak funkcji”. Serwer działał, narzędzia były gotowe do użycia, ale interfejs użytkownika uparcie twierdził, że ich nie ma. Błąd ten był na tyle uporczywy, że zgłoszenia na jego temat pojawiały się jeszcze w wersji 0.116.0, co sugeruje, że korzenie problemu sięgały głębiej i nie każda konfiguracja została od razu naprawiona.

Źródło błędu i mechanizm naprawy

Gdzie tkwiło sedno problemu? Jak to często bywa w programowaniu, chodziło o niespójność w przetwarzaniu danych. Jak wynika z analizy kodu, błąd leżał w sposobie, w jaki Codex poddawał sanityzacji w pełni kwalifikowane nazwy narzędzi MCP, a następnie grupował je z powrotem według nazwy serwera dla potrzeb funkcji mcpServerStatus/list.

Proces normalizacji nazw, który miał przygotować je do bezpiecznego użycia w trybie kodu, nie obsługiwał poprawnie myślników. Powodowało to niedopasowania. System szukał narzędzi dla serwera o nazwie moj-serwer, ale w swojej wewnętrznej mapie widział je zapisane w innej formie, na przykład mojserwer lub moj_serwer. Stąd rozbieżność i pusty ekran.

W wersji 0.115.0 wprowadzono konkretne poprawki:

• #14491 (Fix MCP tool calling): Ta zmiana autorstwa @pakrym-oai zaadresowała fundamentalne problemy z wywoływaniem samych narzędzi MCP.
• #14605 (Normalize MCP tool names to code-mode safe form): Kluczowa poprawka, także autorstwa @pakrym-oai. Jej zadaniem była właśnie bezpieczna normalizacja nazw narzędzi, która teraz prawidłowo obsługuje myślniki, nie psując przy tym ich wyświetlania.

Te poprawki były częścią szerszego zestawu ulepszeń dla przepływów MCP i tzw. elicitation. Jak odnotowano w changelogu, stały się one „bardziej odporne na błędy dzięki bezpieczniejszej normalizacji nazw narzędzi i zachowywaniu tool_params w promptach zatwierdzeń”.

Dlaczego ta poprawka ma znaczenie dla użytkownika?

Można pomyśleć – to tylko myślnik. Ale w praktyce deweloperskiej, szczególnie w obszarach takich jak DevOps czy hosting, nazwy z myślnikami są wszechobecne. Konwencje nazewnicze takie jak docker-compose, cloud-build czy github-actions są standardem. Deweloper konfigurujący serwer MCP do integracji z takimi narzędziami naturalnie nada mu nazwę github-actions-helper.

Przed poprawką, po takiej konfiguracji, użytkownik tracił możliwość wizualnej weryfikacji w CLI. Nie widział, czy integracja faktycznie się udała i jakie komendy są dostępne. Musiał polegać na pamięci, zgadywać lub – co gorsza – próbować wywołać narzędzie na ślepo, licząc, że zadziała. To tworzyło niepotrzebną warstwę frustracji i niepewności, która jest zupełnie niepożądana w narzędziu mającym przyspieszać pracę.

Dla lekkiego agenta kodującego, jakim jest Codex CLI, bezpośrednia, transparentna komunikacja z użytkownikiem w terminalu jest kluczowa. Zaufanie do agenta polega na tym, że dokładnie wiadomo, czym dysponuje i jakie operacje może wykonać. Błąd z wyświetlaniem narzędzi podważał to zaufanie dla całej grupy użytkowników. Jego naprawa to nie tylko kwestia zgodności technicznej, ale też poprawa ergonomii i przewidywalności środowiska pracy.

Szerszy kontekst rozwoju Codex CLI 0.115.0

Warto na chwilę odejść od tego konkretnego błędu i spojrzeć na niego jako na element większej układanki. Wydanie 0.115.0 było znaczące. Oprócz tej drobnej naprawy wprowadziło całą gamę nowości: inspekcję wizualną obrazów w pełnej rozdzielczości, bogatszy REPL dla JavaScript, obsługę WebSocketów w czasie rzeczywistym, nową wersję RPC dla systemu plików (v2) oraz poprawki niezawodności dla subagentów.

Fakt, że w takim wydaniu znalazł się czas na dopracowanie obsługi myślników w nazwach MCP, mówi sam za siebie. Pokazuje, że twórcy Codexa traktują infrastrukturę MCP nie jako dodatek, ale jako filar architektury. To przez MCP Codex rozszerza swoje możliwości o niestandardowe narzędzia, pluginy i zewnętrzne serwisy. Gdy ten filar ma rysę, cała konstrukcja staje się mniej stabilna.

Co ciekawe, changelog wspomina też o trendzie pakowania konfiguracji MCP w pakiety pluginów, które można łatwo wykorzystywać w różnych projektach i przepływach AI. To kierunek, w którym rozwija się ekosystem – w stronę modularności i reużywalności. A w modularnym systemie spójne i niezawodne zarządzanie nazwami oraz zależnościami jest absolutnie fundamentalne. Naprawa z wersji 0.115.0 to mały, ale konieczny krok w tym kierunku.

Podsumowanie

Poprawka błędu z wyświetlaniem narzędzi MCP dla serwerów z myślnikami w nazwie w Codex CLI 0.115.0 to doskonały przykład na to, że w rozwoju oprogramowania detale mają znaczenie. To nie była spektakularna nowa funkcja, ale zmiana, która bezpośrednio wpłynęła na komfort pracy części użytkowników, eliminując źródło dezorientacji i potencjalnych błędów.

Pokazuje to dojrzałość projektu, którego twórcy nie tylko pędzą do przodu z nowymi funkcjami, ale też zaglądają w zakamarki istniejącego kodu, by wygładzić nierówności. Dla deweloperów korzystających z Codex CLI w obszarach web developmentu, AI czy vibe codingu, gdzie integracje z różnymi narzędziami są na porządku dziennym, to ważna wiadomość. Ich konfiguracje, często korzystające z popularnych nazw z myślnikami, będą teraz działały tak przejrzyście, jak powinny od początku. A w świecie automatyzacji i współpracy z AI przejrzystość jest często tym, co oddziela płynny workflow od walki z narzędziem.