OpenAI Codex release notes: Sites behöver en rollout-check före publicering

OpenAI Codex release notes från 2 juni är inte bara en notis om ännu en funktion i appen. Sites i Codex-appen visar hur snabbt ett utkast från en prompt kan bli en driftad webbapp. För ett team som vill testa en enkel instrumentpanel, ärendelista eller intern demo är det lockande. För ett team som saknar release-rutin är det också precis där misstag kan bli publika.

Det praktiska svaret är: använd Sites som en granskningsbar prototypväg, inte som en genväg runt ansvar. Spara versioner, kontrollera åtkomst, granska ändringar och publicera först när någon kan äga supporten.

Källa: Codex changelog, 2 juni 2026

OpenAI Codex release notes: vad Sites ändrar

Codex-appen är OpenAI:s skrivbordsapp för kodagentarbete i lokala projekt. En kodagent kan läsa projektfiler, föreslå ändringar och ibland köra kommandon. Sites är en Codex-plugin som kan skapa, spara, publicera och inspektera webbplatser, webbappar och spel som hostas av OpenAI.

Det förändrar inte bara utvecklarens arbetsflöde. Det förändrar överlämningen mellan idé och drift. En intern prompt kan bli något som kollegor faktiskt klickar på. Därför behöver varje Sites-test ha en tydlig gräns mellan sparad version, granskad version och publicerad URL.

Källa: Sites – Codex | OpenAI Developers

När Sites är användbart för Hammer-läsare

Sites passar bäst när arbetet är konkret men fortfarande avgränsat. Tänk inte “nytt affärssystem”. Tänk “kan vi visa rätt data, rätt formulär och rätt beslutssteg innan någon bygger en permanent integration?”

Bra första kandidater:

• Intern ärendelista: en enkel vy över inkommande förfrågningar, ansvarig person och nästa steg.
• Mini-instrumentpanel: ett sätt att visa status, risk eller handläggningstid utan att koppla in hela datalagret.
• Utbildnings- eller onboardingverktyg: en liten webbapp där medarbetare testar ett flöde innan det hamnar i skarp drift.
• Kunddemo: en prototyp som visar en process, men som bara använder testdata och begränsad åtkomst.

Då blir Sites ett Verktygssmide-problem: bygg något litet som går att granska, ändra och kasta om det inte håller.

Kontrollpunkten ska ligga före publicering

OpenAI beskriver att en ny webbplats kan hållas begränsad till ägare och administratörer i arbetsytan innan den delas vidare. Det är en bra standard även för mindre organisationer: börja med den snävaste åtkomsten och öppna först när innehåll, datakällor och ansvar är kontrollerade.

Innan någon delar en Sites-URL bör ni kontrollera:

• Publik eller intern? Vem ska faktiskt kunna öppna länken?
• Vilken version? Är det den sparade versionen ni granskade, eller en senare agentändring?
• Vilka hemligheter? API-nycklar, miljövariabler och kunddata ska inte klistras in i chatten eller sparas i källfiler.
• Vilka ändringar? Granska ändrade filer och eventuell databaslogik innan publicering.
• Vem äger supporten? Någon måste kunna stoppa, ändra eller ta ned sidan om användare fastnar.

Källa: Sites access and review guidance

En bättre prompt för säkrare Codex-test

Om teamet vill prova Sites, börja med en prompt som bromsar publiceringen:

@Sites Granska detta projekt som kandidat för Sites. Kontrollera om det kan sparas som version utan att publiceras. Lista minsta ändringar, datakällor, miljövariabler och risker. Stoppa innan deployment och ge mig ett beslut: spara, ändra eller avstå.

Ett användbart svar ska inte bara säga “det går”. Det ska visa vad som ändras, vilken åtkomst som behövs, hur testdata används och vilket beslut en människa behöver ta.

Därför uppdaterar vi den här Codex-sidan

Search Console visar att Hammer redan syns för sökningar efter Codex release notes, men att klickfrekvensen är svag. Det betyder att sidan behöver svara snabbare på rätt fråga: “Vad ändrades, påverkar det min utrullning, och vad ska jag testa innan jag uppdaterar eller publicerar?”

För Codex-sidorna är målet inte fler nyhetssammanfattningar. Målet är bättre beslutsstöd:

• version eller datum,
• vilken yta som ändrades: CLI, app, fjärrstyrning, plugin eller mobil,
• risk för inloggning, MCP/pluginåtkomst, filskrivning, loggar eller publicering,
• ett litet testrepo eller testprojekt,
• rollback om något blir fel.

Relaterade Codex-sidor hos Hammer: CLI 0.135.0 och diagnostik, app 26.602 som rollout-check och Codex 0.143.0 med plugins och fjärrflöden.

Praktisk rollout-check för Sites

Använd den här kontrollen innan Codex får göra något publikt:

• Välj ett testprojekt: ingen kunddata, inga riktiga betalningar, inga skarpa behörigheter.
• Be om sparad version först: publicera inte i samma prompt som skapar prototypen.
• Granska diff och beroenden: särskilt miljövariabler, databas, auth och externa anrop.
• Sätt åtkomst snävt: ägare/admin först, sedan workspace eller utvald grupp.
• Dokumentera beslutet: varför publicerade ni, vem godkände, vad ska följas upp?
• Planera avpublicering: en intern webbapp utan stopprutin är inte klar.

Om det här låter tungt för en liten prototyp är det också poängen. En prototyp som ingen äger blir snabbt ett internt system utan support. Hammer kan hjälpa till att göra den första Sites- eller Codex-rutinen liten nog att testa, men tydlig nog att drifta.