{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihy42clsgbvtxm6gd354e3pcjzjh7du5gjymrdipcmn6t22ltbm54",
    "uri": "at://did:plc:lk3jfj3zq4k4wxnk474axylu/app.bsky.feed.post/3mj5sepdlw722"
  },
  "path": "/t/this-search-box-ui-in-the-codex-windows-app-is-bug/1378765#post_1",
  "publishedAt": "2026-04-10T14:49:06.000Z",
  "site": "https://community.openai.com",
  "textContent": "I ran into a really strange UI issue in the Codex Windows app.\n\nWhen 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.\n\nBut the moment I actually try to interact with it, things get weird.\n\nAfter testing it over and over, the behavior is pretty consistent:\n\nBecause 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\n\nonly a **very thin horizontal strip in the middle** of the search box is actually interactive.\nIf 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.\n\nSo what I see on screen is a search box, but what the mouse is hitting does not always behave like one.\n\nI spent some time testing this horizontally and vertically.\n\nIf I move across the middle, that narrow strip is mostly interactive.\nIf I move up or down just a little, interaction disappears right away.\n\nI tested this in both maximized and restored window states, and I could reproduce it in both.\n\nThere is another detail that makes it even stranger.\n\nAfter 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.\n\nSo my impression at this point is pretty simple:\n\n**the visible area of the search box and its actual hit area are not the same thing.**\n\nIt 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.\n\nMy guess is that the hit-testing in the top area is split incorrectly.\nThe 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.\n\nI 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.\n\nBut on my end, this is very easy to reproduce, and the pattern is very clear.\n\nIf anyone else is on Windows, try this:\n\nopen 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.",
  "title": "This search box UI in the Codex Windows app is BUG"
}