<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Codex</title><link>https://blog.ast.moe/en/tags/codex/</link><description>Recent posts: Gorimuchu</description><generator>Hugo</generator><item><title>The Codex CLI kept prompting for re‑authentication each time it started, so I restarted the background server.</title><link>https://blog.ast.moe/en/blog/2026-09-26-2/</link><pubDate>Sat, 26 Sep 2026 19:07:00 +0900</pubDate><guid>https://blog.ast.moe/en/blog/2026-09-26-2/</guid><description>&lt;p&gt;When I launch the Codex CLI, it always displays “Welcome to Codex, OpenAI&amp;rsquo;s command-line coding agent” and prompts me to re‑authenticate from &lt;code&gt;Sign in with ChatGPT&lt;/code&gt;. Even after logging in, the same screen appears again on the next startup.&lt;/p&gt;
&lt;p&gt;Since there was an issue this morning, I initially thought the service might still be unstable and confused that with this behavior. However, when I changed the launch method locally and compared the results, the re‑authentication screen this time was tied to the state of the local background server. I’m not sure whether this morning’s outage caused that state.&lt;/p&gt;</description></item><item><title>I created ctx-sync, a CLI tool that shares development context across multiple sandboxes.</title><link>https://blog.ast.moe/en/blog/2026-09-23-3/</link><pubDate>Wed, 23 Sep 2026 22:37:00 +0900</pubDate><guid>https://blog.ast.moe/en/blog/2026-09-23-3/</guid><description>&lt;p&gt;When you develop by running multiple sandboxes simultaneously, it’s convenient that each environment is isolated, but it can become unclear what the other sandboxes are doing.&lt;/p&gt;
&lt;p&gt;For example, suppose you conduct research and decide on a design approach in one sandbox, then begin implementation in another. The new sandbox has no prior conversation, so you don’t know why that approach was chosen or what issues remain unresolved. As a result, you may end up repeating the same research or re‑examining decisions that have already been made. It can also happen that one worker unintentionally edits a file another worker is working on, causing their work to clash.&lt;/p&gt;</description></item><item><title>Enabled the Visual Store to retain judgment results.</title><link>https://blog.ast.moe/en/blog/2026-09-21-2/</link><pubDate>Mon, 21 Sep 2026 19:55:00 +0900</pubDate><guid>https://blog.ast.moe/en/blog/2026-09-21-2/</guid><description>&lt;p&gt;I updated the
&lt;span&gt;
&lt;a target="_blank" href="https://github.com/ieee0824/visual-store"&gt;
Visual Store
&lt;/a&gt;
&lt;img class="external-link-icon" src="https://blog.ast.moe/images/outer-link.png" width="12" height="12" alt="" aria-hidden="true" loading="lazy"&gt;
&lt;/span&gt;
.&lt;/p&gt;
&lt;p&gt;This time, I added a Judgment Layer that records, for each image, the decision made before actually opening the screenshot and the verification results after it is opened.&lt;/p&gt;
&lt;p&gt;In the previous article “I created a Visual Store to prevent coding agents from hoarding images” (see 2026‑09‑16.md), I described a mechanism for saving images and retrieving only the ones needed. (&lt;a href="https://blog.ast.moe/en/blog/2026-09-16/"&gt;related article&lt;/a&gt;)&lt;/p&gt;
&lt;h2 id="background"&gt;Background&lt;/h2&gt;
&lt;p&gt;The Visual Store was created to store debugging screenshots locally instead of embedding them directly into conversations, so that only the necessary screenshot can be retrieved later.&lt;/p&gt;</description></item><item><title>Added evaluation JSONL and production‑ready features to Jev MCP.</title><link>https://blog.ast.moe/en/blog/2026-09-21/</link><pubDate>Mon, 21 Sep 2026 15:55:00 +0900</pubDate><guid>https://blog.ast.moe/en/blog/2026-09-21/</guid><description>&lt;p&gt;I updated the
&lt;span&gt;
&lt;a target="_blank" href="https://github.com/ieee0824/jev-mcp"&gt;
jev-mcp
&lt;/a&gt;
&lt;img class="external-link-icon" src="https://blog.ast.moe/images/outer-link.png" width="12" height="12" alt="" aria-hidden="true" loading="lazy"&gt;
&lt;/span&gt;
.&lt;/p&gt;
&lt;p&gt;In the previous post, I wrote that we had created an MCP server that invokes Jev, TypeSafe AI’s decision model, from Codex. Simply connecting the four decision tools doesn’t tell us whether they can be reliably used in actual coding work.&lt;/p&gt;
&lt;p&gt;This time, we added a small JSONL file for evaluating the decision results, an evaluation CLI, telemetry for monitoring invocation status, and handling for failures. We have also expanded the Codex‑specific Skill with additional decision recipes tailored to different use cases.&lt;/p&gt;</description></item><item><title>I created an MCP server that extracts Codex’s decisions for Jev.</title><link>https://blog.ast.moe/en/blog/2026-09-20-2/</link><pubDate>Sun, 20 Sep 2026 18:29:44 +0900</pubDate><guid>https://blog.ast.moe/en/blog/2026-09-20-2/</guid><description>&lt;p&gt;I created an MCP server called
&lt;span&gt;
&lt;a target="_blank" href="https://github.com/ieee0824/jev-mcp"&gt;
jev-mcp
&lt;/a&gt;
&lt;img class="external-link-icon" src="https://blog.ast.moe/images/outer-link.png" width="12" height="12" alt="" aria-hidden="true" loading="lazy"&gt;
&lt;/span&gt;
.&lt;/p&gt;
&lt;p&gt;It is intended to be invoked during Codex work to call the TypeSafe AI decision model Jev. Implemented in Rust, it communicates with Codex via standard input/output.&lt;/p&gt;
&lt;span&gt;
&lt;a target="_blank" href="https://docs.typesafe.ai/introduction"&gt;
Jev, TypeSafe AI’s decision model
&lt;/a&gt;
&lt;img class="external-link-icon" src="https://blog.ast.moe/images/outer-link.png" width="12" height="12" alt="" aria-hidden="true" loading="lazy"&gt;
&lt;/span&gt;
&lt;p&gt;Instead of handing the entire coding task over to another agent, I want to extract the small decisions that arise during the investigation.&lt;/p&gt;
&lt;p&gt;For example, questions like “Is this file related to the current bug?” or “Which subsystem should be examined next?” While Codex continues the investigation, editing, and testing, we use Jev for the intermediate classification and evaluation.&lt;/p&gt;</description></item><item><title>What does Codex’s “Error running remote compact task: {"detail":"Bad Request"}” mean?</title><link>https://blog.ast.moe/en/blog/2026-09-17/</link><pubDate>Thu, 17 Sep 2026 11:53:02 +0900</pubDate><guid>https://blog.ast.moe/en/blog/2026-09-17/</guid><description>&lt;p&gt;When you have been working on Codex for a long time, &lt;code&gt;remote compact&lt;/code&gt; may be triggered. At that point, the following error can appear:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"&gt;&lt;code class="language-text" data-lang="text"&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;Error running remote compact task: {&amp;#34;detail&amp;#34;:&amp;#34;Bad Request&amp;#34;}
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;This indicates that Codex’s context‑compression process did not complete successfully.&lt;/p&gt;
&lt;p&gt;However, &lt;code&gt;{&amp;quot;detail&amp;quot;:&amp;quot;Bad Request&amp;quot;}&lt;/code&gt; is not a specific cause name. From just this display alone, you cannot tell whether the context was too large, there were too many images, the history entries were invalid, or it was a temporary server‑side issue.&lt;/p&gt;</description></item><item><title>I created a Visual Store to prevent coding agents from accumulating images.</title><link>https://blog.ast.moe/en/blog/2026-09-16/</link><pubDate>Wed, 16 Sep 2026 18:55:53 +0900</pubDate><guid>https://blog.ast.moe/en/blog/2026-09-16/</guid><description>&lt;p&gt;I created a local image storage called Visual Store (&lt;a href="https://github.com/ieee0824/visual-store"&gt;source&lt;/a&gt;).&lt;/p&gt;
&lt;p&gt;When implementing UIs or checking browser rendering with a coding agent, I often end up taking many screenshots. Displaying all those images in the conversation not only adds the images themselves but also increases the amount of data in the conversation history.&lt;/p&gt;
&lt;p&gt;This time, I built a system that separates the act of saving images from showing the images to the AI.&lt;/p&gt;</description></item><item><title>We recovered from a remote compact failure in a long-running Codex session that contained a large number of uncompressed PNGs.</title><link>https://blog.ast.moe/en/blog/2026-09-11-2/</link><pubDate>Fri, 11 Sep 2026 21:25:17 +0900</pubDate><guid>https://blog.ast.moe/en/blog/2026-09-11-2/</guid><description>&lt;p&gt;The thread that had been running for a long time on Codex suddenly stopped working.&lt;/p&gt;
&lt;p&gt;The error that was displayed is as follows.&lt;/p&gt;
&lt;p&gt;If you only want to understand the meaning of this error, it is explained in “What does Codex’s ‘Error running remote compact task: {&amp;ldquo;detail&amp;rdquo;:&amp;ldquo;Bad Request&amp;rdquo;}’ mean?” (&lt;a href="https://blog.ast.moe/en/blog/2026-09-17/"&gt;source&lt;/a&gt;). In this article, I will describe the steps we took to investigate the history and restore the thread.&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"&gt;&lt;code class="language-text" data-lang="text"&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;Error running remote compact task: {&amp;#34;detail&amp;#34;:&amp;#34;Bad Request&amp;#34;}
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;If it had failed only once, a simple retry would have worked, but in this thread every time we tried a compact we received the same HTTP 400 error, and eventually even the normal responses began to fail.&lt;/p&gt;</description></item></channel></rss>