This search box UI in the Codex Windows app is BUG

I ran into a really strange UI issue in the Codex Windows app.

When I press Ctrl + F, the search box shows up normally. Visually, it looks completely fine. It sits at the top like a normal search field, nothing obviously broken about it.

But the moment I actually try to interact with it, things get weird.

After testing it over and over, the behavior is pretty consistent:

Because of new-user posting limits, I can only include one image, so I used the one below. The cursor can only interact with the search box when it is exactly on that very thin red line. If it is even slightly above or below it, it stops interacting with the search box and only triggers window behavior instead

only a very thin horizontal strip in the middle of the search box is actually interactive. If I move the mouse slightly upward or downward — even though I am still visually inside the search box — it immediately stops behaving like a search box. At that point, clicking starts acting more like window dragging , and in some spots it can even trigger the usual double-click restore / maximize title bar behavior.

So what I see on screen is a search box, but what the mouse is hitting does not always behave like one.

I spent some time testing this horizontally and vertically.

If I move across the middle, that narrow strip is mostly interactive. If I move up or down just a little, interaction disappears right away.

I tested this in both maximized and restored window states, and I could reproduce it in both.

There is another detail that makes it even stranger.

After clicking the close button on the right side of the search box, if I keep the mouse still and double-click, sometimes the window does not restore. But if I move the mouse slightly up or down and then double-click again, it suddenly goes back to behaving like a title bar area — restorable, draggable, all of that.

So my impression at this point is pretty simple:

the visible area of the search box and its actual hit area are not the same thing.

It feels like only that thin strip in the middle is really being treated as the search box, while the upper and lower parts — even though they still visually belong to it — are still acting like title bar / drag-region territory.

My guess is that the hit-testing in the top area is split incorrectly. The search box is clearly being drawn there, but the layer handling mouse input does not line up with what is being shown on screen. That is what makes it feel like I am clicking on a search field while the window behaves as if I clicked on its chrome instead.

I do not have access to the source code, so I am only describing what I can reproduce from the user side. I am not trying to overstate the exact implementation.

But on my end, this is very easy to reproduce, and the pattern is very clear.

If anyone else is on Windows, try this:

open the search box with Ctrl + F, then click across the middle of the search box and also slightly above and below that line. The difference becomes obvious very quickly.