Rust

After implementing Omoikane’s DOM and exception notifications, we ended up investigating copying and garbage‑collection lifetimes as well.

Sat, 10 Oct 2026 17:42:29 +0900

We added DOM operations such as before() and replaceChildren() to Omoikane, along with window.onerror and notifications for unhandled Promise rejections. [PR #1322](https://github.com/ieee0824/omoikane/pull/1322) This is about that pull request. The initial issue was straightforward: the page lacked the APIs it normally calls. However, as we progressed with implementation and testing, we ended up fixing issues such as copying sibling lists when inserting HTML text, rebuilding the entire document after UTF‑16 appends, creating unnecessary iframe realms, and even addressing insufficient GC roots for Promises.

Integrating Jev into Izanagi’s behavioral analysis

Fri, 09 Oct 2026 10:03:32 +0900

In the previous article (source), we introduced Izanagi, which isolates and runs development commands while recording file accesses and network communications. This time, we discuss the addition of behavior analysis using Jev.

Existing detection rules issue warnings based on a single action—such as an attempt to open a secret file, a connection to an address outside the allowed list, or the execution of an unexpected command. In addition, we have made it possible to link multiple actions together in chronological order.

What can be done with Izanagi

Thu, 08 Oct 2026 22:24:12 +0900

When you run npm install, it not only downloads the package but may also execute scripts that the package provides. If you run that code in your regular development environment, you can access files readable by the executing user and the environment variables passed to the process.

To isolate such development commands and track what they access, we have built Izanagi in Rust (source). It records file accesses, network communications, and child‑process launches so you can examine the behavior of the executed code.

WeakMap and Generational Garbage Collection

Thu, 08 Oct 2026 21:52:45 +0900

Opening https://tokyo6.tokyo/ with Omoikane caused a bug where the script terminated with a SIGSEGV during execution. Issue #1223 (issue #1223) reproduces the problem not only in the GUI but also in the screenshot feature that renders the screen to an image. The backtrace from the debug build reproduced on a Linux aarch64 Docker development environment with Xvfb showed that Boa’s garbage collector halted while traversing references to an object.

The fix in PR #1260 (PR #1260) addressed the combination of an ephemeron—a conditional reference—and the generational garbage collector. A young object that was referenced by an older object was being reclaimed during the minor GC that followed a major GC. Subsequently, the major GC followed a reference that had already been freed, causing a crash.

The object returned by Boa’s getter was collected by the garbage collector while the inline cache was being updated.

Wed, 30 Sep 2026 08:12:00 +0900

When running the test for a custom element associated with a form in Omoikane’s Web Platform Tests (WPT), it caused a SIGSEGV. The first occurrence was in a configuration that included the JIT, so we initially suspected an interaction between Boa’s JIT or its garbage collector. However, even when the JIT was disabled, the same crash could be reproduced (issue #858), and ultimately the problem lay in a tiny interval between when the getter’s returned object was produced and when it was stored in the VM’s registers.

Since generating realms with Omoikane was slow, I looked into Boa’s scope lookup and lexical analysis.

Tue, 29 Sep 2026 18:25:00 +0900

In the blog post investigating Omoikane’s CI wait times, we wrote about avoiding heavy verification for changes that only affect documentation and about revisiting the build cache. Separate from that, the tests that actually needed to be run were also taking a considerable amount of time. (source)

Omoikane uses Boa to execute JavaScript. Each time a JavaScript realm is created for a page or an iframe, a large script that sets up the DOM API is run. This processing accounted for a substantial portion of the test runtime. In Issue #1154, instead of reducing the number of tests or realms, we investigated this initialization itself.

As AI-driven development progressed, the 30‑minute CI wait became increasingly burdensome, so I revisited the validation of Omoikane.

Tue, 29 Sep 2026 10:20:00 +0900

When developing with AI coding agents such as Claude Code and Codex, you can work on implementation and research in parallel. Tasks that used to take one at a time can now be tackled multiple on the same day. However, the CI that runs after a pull request is submitted does not speed up to match your pace.

My custom browser, Omoikane (source), has a large Rust codebase, and the internal Boa component resides in a separate Cargo workspace. Testing spans Linux and macOS, various architectures, WPT, and more. Because Rust compiles based on dependencies, features, and targets, this setup especially highlights long build wait times. Even if the agent can generate the next change, the verification of previous changes keeps piling up without finishing.

Fixed the origin‑boundary bypass that was present in the internal host function of Omoikane.

Sat, 26 Sep 2026 07:06:58 +0900

During the development of Omoikane, I happened to notice that the internal __omoikane_* function was visible from the page’s JavaScript. By examining the code, I confirmed through static analysis that passing a different Document or Node ID could create a path that reaches the DOM, cookies, or storage of a cross‑origin document without going through the same‑origin policy. I did not create a proof‑of‑concept that actually reproduced the read/write behavior before the fix. After the fix, I verified in regression tests that cross‑origin access is properly blocked.

JavaScript Realms as Seen Through Omoikane’s iframe Implementation

Fri, 25 Sep 2026 19:04:46 +0900

When working with iframes in my custom browser Omoikane , I kept coming back to the concept of Realms. At first I thought of it as simply “creating a separate JavaScript execution environment for child frames.” However, merely creating a separate environment wasn’t enough. When a parent accesses the child’s Array, when an iframe navigates to a different page, or when a timer that was scheduled in the child later fires, it becomes necessary to determine which Realm’s values are being used for which Document in each case.

A SIGSEGV occurred after garbage collection because the iterator function passed to Boa’s Array.from was not properly retained.

Fri, 25 Sep 2026 08:46:00 +0900

While running Omoikane’s Acid3 test, the process hit a SIGSEGV under the baseline JIT configuration on macOS ARM64. I briefly mentioned this in the earlier blog post about Omoikane updates, but the cause wasn’t the test itself nor the JIT’s machine‑code generation; it lay in the Boa code we’re incorporating, specifically in the Array.from() section. Omoikane incorporates Boa’s source code together with the browser‑side implementation, so the fix was also applied to the engine that pulls in that code. (source)

Evaluation of FP6 Quantization in Small-Scale Image Super‑Resolution DNNs: Condition Exploration and Comparison of Residual and Direct Generation Architectures

Thu, 24 Sep 2026 22:07:00 +0900

Overview

We compared image quality and file size when using a small image‑upscaling DNN with FP16 weights converted to FP6. In the search for optimal quantization settings, the PSNR improved on four validation images but decreased on another set of four images. Afterwards, we evaluated using 174 images divided into five groups by acquisition series, as well as 12 images that had not been used until the FP16 baseline was fixed. Even with roughly the same number of parameters, the degradation caused by uniform conversion to FP6 differed markedly between residual‑type and direct‑generation‑type models. The comparison of the 12 final FP6 images was added after viewing the FP16 results, so it does not constitute a new blind evaluation.

I created ctx-sync, a CLI tool that shares development context across multiple sandboxes.

Wed, 23 Sep 2026 22:37:00 +0900

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.

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.

I advanced browser compatibility for cookies and scrolling in Omoikane.

Wed, 23 Sep 2026 21:39:00 +0900

In my custom browser Omoikane , I made several changes related to Web API and CSS compatibility.

Looking at these changes, many of them went beyond simply adding APIs visible to JavaScript. It was necessary to convey the page’s state to the host, reflect JavaScript actions in HTTP communication, and preserve the scroll position set by CSS until the input processing is finished.

Cookies were handled separately for JavaScript and HTTP

The first thing we fixed was how cookies are managed.

Visual Store now supports libvpx 1.12 on Debian 12 ARM64.

Wed, 23 Sep 2026 07:55:00 +0900

I updated the Visual Store .

In the previous article “Added the ability to retain judgment results in Visual Store” (linked to 2026-09-21-2.md), I wrote about the new Judgment Layer that saves the decisions and verification results before an image is opened. This time, rather than introducing a new feature, I’m addressing the issue where the default build with VP9 enabled fails to compile on Debian 12 ARM64, and I’ve revised the procedure for reporting bugs in the Visual Store Skill. (related article)

I'm fixing subtle web‑compatibility differences in Omoikane.

Tue, 22 Sep 2026 07:09:00 +0900

When I’m tinkering with my own browser, Omoikane , I’ve found that the tiny differences that are taken for granted in existing browsers can be more troublesome than implementing a single large web API.

The changes I added this time are the default margin for body, declarative Shadow DOM, and the orientation of characters in vertical text. Each of these looks like a small visual tweak, but each relies on assumptions in the CSS cascade, HTML parsing, and text rendering, respectively.

Enabled the Visual Store to retain judgment results.

Mon, 21 Sep 2026 19:55:00 +0900

I updated the Visual Store .

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.

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. (related article)

Background

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.

Added evaluation JSONL and production‑ready features to Jev MCP.

Mon, 21 Sep 2026 15:55:00 +0900

I updated the jev-mcp .

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.

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.

I created an MCP server that extracts Codex’s decisions for Jev.

Sun, 20 Sep 2026 18:29:44 +0900

I created an MCP server called jev-mcp .

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.

Jev, TypeSafe AI’s decision model

Instead of handing the entire coding task over to another agent, I want to extract the small decisions that arise during the investigation.

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.

Implemented Pointer Lock and form‑related custom elements in Omoikane.

Sun, 20 Sep 2026 11:25:48 +0900

I added Pointer Lock support and custom form‑related elements to my self‑made browser ( Omoikane ).

In the previous post I wrote about Fullscreen API and character‑encoding conversion streams. This time I’m covering the pathway for delivering mouse input to the page and the logic for integrating my custom input components into HTML forms.

Neither of these is a huge undertaking if you only consider the entry‑point APIs. However, when we actually hooked everything up, we ran into issues such as mouse input being delivered twice on X11, iframe callbacks executing in a different runtime environment, and even pages that don’t use forms becoming sluggish. In the end, the macOS tests caused the entire process to crash.

Implemented the Fullscreen API and character‑encoding conversion streams in Omoikane.

Sat, 19 Sep 2026 20:46:07 +0900

I added the Fullscreen API and TextEncoderStream/TextDecoderStream to my custom browser, Omoikane .

Previously, I implemented the Popover API and a top layer (see /blog/2026-09-14/). This time, I connected that rendering pipeline to the Fullscreen API and, as a separate task, made character‑encoding conversion usable via the Streams API. (source)

Fullscreen display and character‑encoding conversion are fairly unrelated features. However, neither could be completed simply by adding a JavaScript method.

Development notes for Cubase MCP. I'm having trouble with the preliminary research before retrieving the track list.

Sat, 19 Sep 2026 20:28:17 +0900

Previously, I wrote an article titled “Building a Server to Control Cubase via MCP” (source).

Since then, I’ve continued developing cubase_mcp , but it hasn’t progressed as much as I had hoped.

I’ve now managed to handle play/stop and retrieve transport status, so the next step is to obtain a list of the project’s tracks.

If we can retrieve information such as the track name, selection state, mute, and solo status, we could expand what’s possible from MCP. That was the premise, but now I’m still investigating what exactly can be retrieved and how far.

We have released a compatible simulator “lqs” for testing SQS locally.

Sat, 19 Sep 2026 20:05:53 +0900

I have released a compatible simulator for testing SQS locally, lqs . The name is an abbreviation of local queue service.

It provides an HTTP API that can be accessed from the AWS SDK, allowing you to test locally operations such as sending and receiving messages for both Standard and FIFO queues, visibility timeouts, and moving messages to a DLQ.

Since all the issues I had prepared have been resolved, I decided to make it public.

I created a Visual Store to prevent coding agents from accumulating images.

Wed, 16 Sep 2026 18:55:53 +0900

I created a local image storage called Visual Store (source).

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.

This time, I built a system that separates the act of saving images from showing the images to the AI.

Implemented the Popover API and top layer in the custom browser Omoikane.

Mon, 14 Sep 2026 16:34:41 +0900

I have implemented the HTML Popover API in my custom browser, Omoikane (source).

With the Popover API, you can open and close popovers using only HTML, without needing to manage their visibility state with JavaScript.

<button popovertarget="menu">Open menu</button>

<div id="menu" popover>
 <button>Item 1</button>
 <button>Item 2</button>
</div>

At first glance, it seems all you’d need to do is add an API to toggle the element’s display state.

In reality, popovers are rendered on a top layer that lies outside the normal stacking order. There are considerations such as light dismissal when clicking outside, closing with the Escape key, focus movement and restoration, ::backdrop, and the ordering relationship with dialogs.

I investigated why Acid3 was crashing due to memory errors in Omoikane’s baseline JIT.

Sun, 13 Sep 2026 20:20:51 +0900

While working on implementing CSS in my own browser, Omoikane (source), Acid3 began crashing due to memory errors.

The problem only occurs when the baseline JIT is enabled; it runs fine with the interpreter.

Furthermore, Omoikane’s Acid3 runner has two execution modes, Faithful and DirectDrive. Faithful completes all 100 points, but then it crashes during DirectDrive.

The failure manifests differently depending on the environment.

Environment	Observed failure
x86_64 Linux	SIGSEGV
ARM64 Linux	SIGABRT, ~60 GB allocation, SIGSEGV on rerun
ARM64 macOS	SIGSEGV, SIGBUS on rerun

Even though it’s the same test, the signals differ.

I made significant progress on the HTML and CSS implementation of my custom browser, Omoikane.

Sat, 12 Sep 2026 19:51:40 +0900

These past few days, I’ve been working on advancing the implementation of HTML and CSS in my custom browser, Omoikane (source).

At first, I displayed the same HTML as Firefox and investigated where any rendering discrepancies remained.

When I began the comparison, I discovered not only simple color differences but also fundamental shortcomings, such as inline elements not having their bounding boxes correctly calculated, web fonts not being manageable from JavaScript, and HTML fragments not being parsed according to the context.

I forgot to keep a Promise alive in Boa, which broke the malloc.

Thu, 10 Sep 2026 20:37:07 +0900

While running Boa’s Test262, the test occasionally failed with exit code 134.

The logs show the following errors:

malloc(): unsorted double linked list corrupted

The issue is the “normal Test262 release run is aborted due to an allocator consistency error” (issue #638).

At first, I assumed some recent change was corrupting memory somewhere. However, because Test262 runs a large number of tests in parallel, the logs alone don’t reveal which specific test is causing the problem.

Boa incorrectly judged stack usage due to ASAN's fake stack.

Thu, 10 Sep 2026 20:14:12 +0900

In the previous article, we fixed the issue where Boa’s parser exhausted a 2 MiB stack. (related article)

We reduced the frame size during recursion and made it return an error for inputs that are too deep. With a normal build, the original Test262 now also passes within the 2 MiB limit.

When we continued diagnosing with AddressSanitizer (ASAN) in that state, it started rejecting even shallow inputs.

parser recursion limit exceeded

The protection we added to prevent stack exhaustion was stopping prematurely, even though the stack hadn’t been fully used. This concerns Issue #640.

Boa's parser exhausted a 2 MiB stack

Thu, 10 Sep 2026 19:58:13 +0900

While running Test262 before importing Boa into Omoikane, we discovered a case where an unoptimized parser aborts due to a stack overflow (issue #633).

The failure occurred in Test262’s regress-672893.js.

It wasn’t a matter of nesting tens of thousands of invalid JavaScript statements. It was valid JavaScript with about fifteen levels of nested function expressions.

If we omit the structural details, the code looks like this:

function f() {
 return function () {
 return function () {
 ...continues in the same pattern up to 15 steps...
 return function (a) {
 var v = a;
 return function () { return v; };
 };
 };
 };
}

f()()() ... ()(42)();

When this code is passed to a Boa built with the dev profile and the thread stack is set to 2 MiB, the parser triggers a stack overflow and exits with status 134.

The Float16 conversion results differed between x86_64 and ARM64.

Thu, 10 Sep 2026 19:11:38 +0900

In the pre‑migration verification of Boa for Omoikane (issue #655), we ran the same Boa and Test262 on Linux x86_64 and ARM64, and the results differed in only 10 cases.

A total of 50,595 cases were executed.

Environment	Passed	Failed	Ignored
Linux x86_64	47,606	933	2,056
Linux ARM64	47,616	923	2,056

The ten cases that differed were all tests related to the conversion to Float16.

It’s problematic that JavaScript results change when the CPU changes even though the source code and inputs are identical. We investigated what was happening.

I built a server that controls Cubase via MCP.

Sun, 16 Aug 2026 08:05:11 +0900

I thought it would be interesting to control Cubase via MCP, so I created the Cubase MCP.

By sending commands such as “play,” “stop,” or “report the current status” from an MCP client, you can operate Cubase’s transport controls and retrieve its state.

It’s not yet possible to control every aspect of Cubase. This time, I first built a small implementation that simply connects MCP to Cubase.

What was created

The implementation is an integration daemon written in Rust.