DEV Community: Orwa Mahmoud

Why Claude Code Stops Halfway Through Long Tasks—and the Harness I Built to Keep It Moving

Orwa Mahmoud — Tue, 28 Jul 2026 17:08:23 +0000

I kept giving Claude Code long task lists, stepping away, and coming back to find it had completed the easy parts and stopped before the difficult ones.

Sometimes it was worse.

Claude would work until 2 AM, ask one non-critical question, and then sit idle for six hours until I woke up at 8.

The question was usually reasonable, but it was not truly blocking. Claude could have chosen a safe default, continued working, and left the decision for me to review later.

That is a harness problem, not only a model problem. The layer around the agent loop decides what “done” means, when the run may stop, and what happens when human input is unavailable.

That problem led me to create Nightshift, an open-source reliability harness plugin for long unattended Claude Code sessions.

Keeping the task outside the conversation

Nightshift uses a persistent Markdown punch list as the source of truth.

# Nightshift Punch List

- [ ] Add rate limiting
- [ ] Add tests for failed login attempts
- [ ] Update the API documentation
- [ ] Run the full test suite

Claude works through the list one item at a time.

Because the work is stored in a file rather than only inside the current context window, the session can recover after context compaction, interruption, or restart.

Preventing quiet early exits

Nightshift includes a stop hook that checks the punch list whenever Claude tries to finish.

If unchecked items remain, the normal stop is blocked and Claude is instructed to continue.

The shift ends only when:

every item is completed
the deadline is reached
an optional stall limit is reached
or the owner explicitly stops it

If no stall limit is configured, stalled work stays held and visibly flagged rather than quietly clocking out.

This is stronger than simply prompting Claude to “continue until finished” because the completion condition is checked against persistent state.

Non-blocking questions should not stop the night

Most human-in-the-loop systems pause the agent whenever it has a question.

That makes sense for destructive or high-risk decisions. It does not make sense for every naming choice, implementation preference, or reversible decision.

During a Nightshift session, non-blocking questions are parked with the default Claude chose.

## Parking Lot

- Question: Should the endpoint return 200 or 201?
- Default used: 201, matching the existing creation endpoints.
- Review later: Confirm API consistency.

Claude continues working, and the developer reviews those decisions in the morning.

The goal is not to remove human oversight. It is to make some of that oversight asynchronous instead of forcing the whole session to wait.

Guardrails for unattended work

Long-running autonomy needs clear boundaries.

Nightshift can mechanically enforce restrictions such as:

blocking git push
denying dangerous commands
protecting selected directories
checking diffs for secret-like content
enforcing a specific Git identity
preventing non-blocking questions from pausing the shift

A prompt saying “do not push” is helpful.

A hook that rejects git push is stronger.

These guardrails are not a security sandbox, but they reduce the risk of relying only on the model to remember every instruction.

Verification before completion

A checked box is still a claim made by the agent.

Nightshift cannot guarantee that the implementation is correct or replace code review. What it can do is enforce a more disciplined workflow:

implement the change
run the relevant verification
inspect the result
commit the completed item
mark the checkbox complete

Verification can include commands such as:

npm test
npm run lint
npm run typecheck

Nightshift also encourages one commit per completed item, making the run easier to inspect or partially revert.

Resumability and receipts

Nightshift stores operational state inside .nightshift/, including punch lists, parked questions, logs, deadlines, stop signals, and completion snapshots.

This state can have its own local Git history, separate from the main project repository.

That gives the developer two different records:

project commits showing what changed
Nightshift receipts showing what happened during the run

If the session is interrupted, a new session can inspect the same state and continue from the remaining work.

What Nightshift does not solve

Nightshift does not eliminate hallucinations.

It does not guarantee that:

every completed item is actually correct
tests cover every requirement
every chosen default is good
every unsafe command will be detected
a poorly written task list will produce a good result

It adds persistence, constraints, verification habits, resumability, and visibility around Claude Code.

Human review is still required.

Installation

Inside Claude Code:

/plugin marketplace add orwa-mahmoud/claude-nightshift
/plugin install nightshift

Then initialize it inside your project:

/nightshift:setup

Review the generated punch list and start the shift:

/nightshift:start

Overview and FAQ:

https://orwamahmoud.com/nightshift/

Nightshift is free, open source, and MIT licensed.

Contributions, issues, and feedback are welcome:

https://github.com/orwa-mahmoud/claude-nightshift

One headless table engine, every React UI kit

Orwa Mahmoud — Sat, 04 Jul 2026 08:06:43 +0000

Every React project reaches for a data table eventually, and the choice always feels like a trap:

Reach for ag-Grid or MUI X DataGrid and you get power — but their look, their DOM, and (for the good features) their license.
Reach for TanStack Table and you get total freedom — but now you build every cell, header, filter, and pagination control from scratch.
Reach for a kit-specific table (Mantine, Chakra, Ant) and you're locked to that one kit, re-learning a new API each time.

I wanted one table that renders natively in whatever UI kit a project already uses, with the same features everywhere, and a headless escape hatch when the defaults aren't enough. So I built AdaptTable.

One API, real native components

The whole table is five lines:

import { DataTable, useFrontendData, type ColumnDef } from "@adapttable/mantine";

const columns: ColumnDef<Person>[] = [
  { key: "name", header: "Name", accessor: (r) => r.name, sortable: true },
  { key: "email", header: "Email", accessor: (r) => r.email },
];

function People({ rows }: { rows: Person[] }) {
  const source = useFrontendData({ data: rows, columns });
  return <DataTable source={source} columns={columns} rowKey={(r) => r.id} />;
}

Swap the import for @adapttable/mui, @adapttable/chakra, @adapttable/antd, @adapttable/radix, @adapttable/shadcn, or @adapttable/unstyled — same props, different kit.

The key part: it is not a wrapper that looks the same everywhere. Each adapter renders that kit's actual components — MUI gets Material elevation, Ant gets Ant's compact density, Chakra gets Chakra's tokens. Same behavior, native skin. Flip the switcher in the live demo and watch one dataset re-render through each kit: https://orwa-mahmoud.github.io/adapttable/demo/

Filters and state that live in the URL

My favorite part: open the filter drawer, set a status and a date range, copy the link — whoever opens it sees the exact same view. Search, filters, sort, and page all serialize into query params (q, page, f_status, …), so every view is refresh-safe, back/forward-safe, and shareable. No useState juggling, no wiring: declare the filters and the URL sync comes with them, identically for client-side data and server-side fetching (there's a router adapter for Next.js and react-router).

What you get for free

Write it once, get all of it across every adapter:

Sorting, filtering (with removable chips), global search
Row selection + bulk actions
Column management — show/hide, reorder, pin (sticky), resize
Pagination — numbered or infinite scroll, auto by device
Shareable URL state + saved views
First-class RTL / Arabic and dark mode
Optional virtualization — a 10k-row list mounts ~24 DOM rows
Client-side data and server-side (you supply the fetch) through one contract

Headless when you need it

Under every adapter is @adapttable/core — a headless engine with prop-getters (getTableProps, getRowProps, …). If the batteries-included adapter isn't enough, drop down and render your own markup on the same engine. You never hit a wall.

What it's not

No pivoting, grouping, or Excel-style editing — this is for the CRUD tables most apps ship, not analytics grids. If you need those, ag-Grid is the right tool.

Try it

Try it in your browser (no install): https://stackblitz.com/github/orwa-mahmoud/adapttable/tree/main/starters/mantine
Live demo (flip the kit switcher): https://orwa-mahmoud.github.io/adapttable/demo/
Docs: https://orwa-mahmoud.github.io/adapttable/
npx @adapttable/cli init
MIT, stable v1 (1.1 just brought every adapter to full feature parity): https://github.com/orwa-mahmoud/adapttable

Feedback very welcome — especially whether the per-kit rendering holds up in your stack, and how the declarative API feels next to what you use today.