Build a To-Do App with Codex: Part 2

Hey y’all, this is part two of building a to-do app with agents. In part one we planned the whole thing—built a master plan and executed the first phase—so right now we’ve got an app living in the browser where you can add tasks, complete them and remove them.

Today we pick up where we left off and finish a few more of these things. Let’s get into it.

We’re still using Codex for this project, so I open it up in the to-do folder—just the index and the plan in here. First thing I do whenever I come back to one of these is ask for the status, just to reorient.

Then I have it open the app in Chrome with the Chrome DevTools MCP so we can actually see where we are. Yep—complete and delete are done. I can add a task, complete it and delete it. That all looks right.

Time to plan phase two. What I want is inline title editing—clicking into a task and making adjustments right there in place. Codex suggests handling title and due-date editing together, but I haven’t put a ton of thought into how I want due dates to behave yet, so let’s keep it to title editing for now.

I ask how the editing should start and it lands on an inline input, which is exactly right.

The more I look at it, the more due dates feel like they add complexity for what’s really a toy app. So I have it remove due date for the time being and make a note to add it back toward the end of the master plan.

It interprets that a little broadly and strips dates out of the plan altogether—close enough for now, we’ll revisit it later.

Before we go further I clear the context. Quick aside on why—context is basically how much the agent is holding in its head, and the more it fills up the worse it performs. You start getting degradation somewhere around 25% used, it gets serious around 50 to 60%, and by 70% is when hallucinations creep in.

We’ve barely talked about anything here, so we’re only at 9%, but it’s a good habit. The Supabase MCP throws a couple of errors on the way—we don’t need it for this project, so no big deal.

Now I can edit titles, but there’s a thing that bugs me—the row jumps when I focus the input. The height changes and everything below it shifts down.

General product-design rule, you don’t want stuff moving right when you’re about to interact with it. I ask what our options are for killing that effect.

There are a few ways to handle it. The agent suggests a content-editable approach and adding a bottom border, but I don’t think we need the border—the highlight does enough and the app’s simple enough to get away without it.

What I do want is to reserve the line height so the row stays put when you focus it. So—keep the height, lose the border. I also have it pull the dates out of the UI while we’re in here.

The jumping’s fixed. Next thing I notice is the hover state—there’s a gray hover area, but below the cursor there’s a strip of white where the padding doesn’t fill, and the hover doesn’t reach all the way to the bottom border. It looks sloppy.

I have it fix the hover so it fills the entire space and runs to the edge.

Feeling good about this. One more thing—the whole card shows a hover state, but to actually focus the text I have to have my cursor right on the text itself. Clicking elsewhere in the row selects the text without letting me edit it, which is almost more confusing.

So I ask—when I click anywhere inside the hover area, focus the text input. Now the text cursor shows up everywhere in the row.

A quick idea I’m sitting on for later—right now creating a task just drops it at the bottom, which was a fine starting point. But what if I want to insert one between two existing tasks? Maybe the empty composer row always stays at the top and I click to move where a new task lands. Not building it now, just thinking out loud.

One thing worth knowing—if the Chrome DevTools MCP is taking screenshots and you’re sitting in the same tab it’s working in, you’ll mess up its screenshots. Give it its own tab.

On to the next item—drag ordering and responsive deletion. Let’s plan it. I don’t want a drag handle. I’d rather the user click and hold for a moment, get a visual indicator that the row is now movable, then drag to reorder. Keep it as simple and minimal as possible.

I should’ve kept it in plan mode but it gets the idea. We go with a 400-millisecond long-press to pick up a row. When you’re dragging, I ask for a glass-like background with a bit of blur on the card that’s moving, and have the other cards fall above or below it in line as you go.

Backdrop filters are a fairly new browser thing—it’s the frosted-glass look Apple leans on. Not the full refractive version, more like a piece of frosted glass where you can tell there’s something behind it but it’s blurry.

Chrome DevTools is fumbling around and I honestly don’t know what’s going on with it, but let’s keep moving. When I drag, I see opacity change but no frosted glass yet, and the edges are pure white.

Part of the problem is the rows sit in a max-width container, so they don’t reach the edge. I have it remove the max width so the rows—and the hover state—run the full width to the edge of the screen, the way the small viewports already do. There’s also a gradient painted on either side that I’m not crazy about, so I have it fill the whole row instead of fading at the sides.

Quick CLI tip—escape interrupts the agent mid-run so you can add a clarification, same as Claude, though in Claude you sometimes hit it twice.

Rows are full-width now and the hover fills the space. But I still don’t have the glass background when dragging. I have it investigate the backdrop blur.

This is one I remember agents struggling with—I’ve applied it to nav bars and fixed elements easily enough, but popovers and floating elements have been harder. On top of that, killing Chrome DevTools and reopening it breaks the dragging itself for a bit—now the card barely moves with the mouse.

I think I need to split these problems up. shadcn/ui is something I use a lot and it’s a good reference—I’m pretty sure they have a translucent treatment for their menus. So I have it do an internet search and use shadcn/ui as a reference for how to properly blur the background of an element being dragged over another.

About here we start bumping into token limits on Codex, so the plan is to fix what we can, save a note and switch over to Claude.

And—there it is. It pulls it off, and you can see the glass background get darker as it passes over the text underneath. I’ll take that as a win.

Codex spent a lot of this session fighting with Chrome DevTools, so I’ll cut that down in the edit. But we added some real polish—inline editing and drag-to-reorder with a nice effect.

I have it update the master plan and leave a note on where we are so there’s something for an agent to pick up next time. I might come back later today and try Claude, see if it has better luck with the Chrome DevTools MCP. Good stopping point—see you next time.