DEV Community: TaskHandoff

Where did I leave that? Managing AI agent sessions across machines

TaskHandoff — Mon, 12 Oct 2026 04:32:50 +0000

Running a coding agent has been getting easier for a while now. The hard part has quietly moved somewhere
else.

It's not the model. It's not the tooling. It's that you can't find the work you did yesterday.

See if any of this is you

You have ten terminal windows open. Seven of them are called codex.
You remember a session that had the tests almost passing. You don't remember which machine it was on.
You closed your laptop, SSH dropped twice, and when you came back you weren't sure what you'd approved.
One session has been running for two hours, and to see the step you actually care about you have to scroll back through three hundred tool messages.

None of these are about how smart the model is. They're about how your work is organized.

This is now an entire product category

Here's a funny way to see the problem clearly: there's a whole class of tools whose only job is answering
"where are my sessions?"

cmux (198 points on HN) — a terminal with vertical tabs and notifications, because you have too many sessions.
Agent-of-empires (118 points) — literally a session manager. Its own README states the problem better than I can: > "Each agent runs in its own tmux session, so your agents keep running when you close the TUI, > disconnect SSH, or your terminal crashes. Reopen aoe and everything is where you left it."
Rudel (144) does session analytics. claude-replay (105) replays sessions like a video player. Ctx (72) adds a /resume that works across Claude Code and Codex. Skillsync (YC W26, 68) makes sessions portable between agents. Pizza Bot (61) gives agents an inbox.

Even the vendors agree that many sessions at once is normal. Anthropic ships docs titled
Orchestrate teams of Claude Code sessions (396 points on HN)
and Message your other Claude Code sessions
(173 points).

And their blog nails what bad session hygiene actually costs:

"In one session, Claude reads the test and the file it covers, makes the edit, and is done in a handful of
turns. In another, it greps around the repo first, reads a dozen files on its way to the same two, and
every one of those turns also drags along everything else that's been read into the conversation since
this morning."

Same fix. Very different bill.

All of those tools hit the same ceiling

Almost every one of them is single-machine and single-agent.

The moment your sessions live on several machines — one at home, one at work, one on a customer's box, one in
the cloud — the session manager can't see them, the replay tool can't replay them, and /resume can't find
them. Your session management silently drops to zero exactly when you need it most.

TaskHandoff organizes sessions around an idea called Story

TaskHandoff is an open-source (Apache-2.0) control plane. The unit it organizes work around is a
Story, and the documentation defines it in one line:

Story — Organize documents, sessions, preset actions, and automation by goal.

The key word is goal, not time. If your goal is "finish the payments refactor," that's one Story holding
the relevant documents, several sessions, the preset actions you keep reusing, and the automation around it —
instead of four terminals you have to remember.

Then there are three things sessions themselves do about the pain above.

1. The session list marks unread sessions.

"Session lists mark unread AI sessions so you can quickly find work that needs attention.
Switch sessions from the instance sidebar, AI board, or Story."

Three places to switch sessions, and anything you haven't looked at is flagged. That answers "what did I miss."

2. Compact mode shows you one turn at a time. This is the part I haven't seen anywhere else:

"TaskHandoff's default and distinctive session experience. It focuses on one selected task turn and
keeps only the prompt, AI response, live tool activity, approvals, queue, and sub-agent state needed for the
current decision. This greatly reduces interference from long histories and repetitive process messages."

A two-hour session stops burying today's decision under hundreds of process messages.

And importantly, it doesn't achieve that by throwing data away:

"Compact mode does not summarize away or delete server-side session data. The complete history remains
available in Conversation mode."

3. Conversation mode is there when you need to dig.

"Use it to reconstruct a task, find an earlier prompt or result, audit approvals and retries, or
understand context across multiple turns."

And one line in the docs is the whole answer to "across machines":

"During a reconnect, TaskHandoff reloads the authoritative session snapshot.
A temporary Reconnecting state does not imply that the background task stopped."

Switch devices, lose the connection, come back — you get the authoritative snapshot, not a partial cache, and
"reconnecting" doesn't mean your background work died.

One more thing worth stealing: Story decisions. When a session produces something that needs a human
call, it doesn't get buried in chat — it becomes a pending item in the approvals queue. "Something is waiting
on you."

Quick start

curl -fsSL https://github.com/edgestorage/task-handoff/releases/latest/download/install-server.sh | sudo sh

The line worth ending on

The last line of TaskHandoff's own "recommended practice" section is:

"Save important results in project files or Story documents, not only chat history."

Chat history disappears. Goals don't.

Honest caveats

Story isn't magic that tidies your sessions for you. It gives you structure — grouping by goal, unread
markers, a pending-decisions queue — and whether you use that structure is still down to your own habits.

If you only have one project on one machine, most of this won't matter to you yet. It's built for people
whose sessions have already started to sprawl.

TaskHandoff is also still Beta — the README says plainly that breaking changes may land between releases.

You can build your own Codex Desktop. The glue is the hard part.

TaskHandoff — Mon, 12 Oct 2026 04:26:38 +0000

There's a genre of blog post you've definitely seen. The title is usually something like "Own the Harness,
Rent the Intelligence."

The argument is correct: your rules, your skills, your tooling should move with you when you change models
or subscriptions — instead of being locked into somebody's account.

Someone recently actually did it, and then wrote a very honest post-mortem.

He pulled it off. Then he went back to Codex Desktop.

The post is I Wanted to Own the Harness. Then Codex Desktop Won.
(Jory Pestorious, Aug 2026). His original draft was called "Own the Harness, Rent the Intelligence."

And he genuinely did achieve portability — "portability is what let me cancel Claude Max without abandoning
my rules."

But he ends up admitting he kept opening Codex Desktop anyway. And the reason he gives is the real thesis
of this article:

"I've built the rest myself more than once. One version combined a terminal harness, a provider,
MCP servers, editor integration, remote access, a scheduler, notifications, voice, and the code
connecting them. A task started in one tool could not see the context in another. An update broke a
path I had forgotten was fragile. The pieces worked, but keeping them connected became its own project."

Every piece worked. The glue became the project.

He puts it even better a few lines later:

"'You can build it yourself' is true in the same way that 'you can change your own oil' is true.
The missing number is what I wanted to do with that Saturday."

What he was actually staying for

The interesting part is that he spells out why he stayed, and those two sentences read like a feature list:

"Codex became the window I kept open. My work sat in visible tasks instead of terminal sessions
I had to remember."

"Remote setup took a QR code. I could talk through an idea, pick up the work from my phone, and
let a scheduled task return to the conversation where it began."

Not "the model is smarter." Not "there are more tools." It's:

Work you can see — instead of terminals you have to remember.
Remote access that just connects — a QR code.
Picking it up from your phone — no re-establishing context.

None of that has anything to do with the model. That's a control plane.

The open-source gap was never the agent

Look at where the open-source energy has actually gone:

OpenCode, an open-source AI coding agent — 1,274 points, 618 comments on HN. The agent layer is solved and thriving.
Plandex, MyCoder, Sidekick, Agentty — there are more open-source agents than anyone can try.
Meanwhile, "run your agent anywhere, on any machine" is almost entirely cloud products: Boxes.dev (105 points / 79 comments), Omnara (YC S25, 147 points / 161 comments).
The one open-source project pointed the same way, Proliferate — "open-source, self-hostable Codex for any coding agent" — sits at 46 points and 16 comments. The seat is basically empty.

And on the other side of the ledger: the Codex app launch post has 805 points and 638 comments on HN.
The "Linux support is finally in preview" post has 469 points and 315 comments.

So: the agent layer is open source and winning. The control plane is closed or hosted.
That gap is exactly why one person gluing it together by hand ends up with a project instead of a setup.

That's the seat TaskHandoff takes

TaskHandoff is an open-source (Apache-2.0) control plane. It doesn't replace your agent — it replaces
the glue that connects people, machines and sessions, and keeps them connected:

Browser / Desktop / Mobile
            │
            ▼
       Control Plane     ← one console: node inventory + instance board + session view
            │
            ▼
         Node Agent      ← one per machine (home, work, customer, cloud)
            │
            ▼
   Controlled Instance   ← one isolated container per session

Mapped to the three things he was actually staying for:

Work you can see → the AI session center. Session state across instances streams in real time over WebSocket, so ten machines are still one board.
Remote access that just connects → install a Node Agent and that machine is a node. No signing up to someone else's cloud, and no QR code handing control to a third party.
Picking it up from your phone → a mobile client. iOS and Android connect directly to the Control Plane you deployed.

Plus the parts that make it hold together: the Node Agent owns instance lifecycles (restart the control
plane, close your browser — the instances keep running, so "a scheduled task returns to the conversation
where it began" doesn't require a hosted service), multi-node management, environment templates,
Controlled Instances with Docker isolation, and managed Git credentials scoped per remote.

It doesn't swap Codex for another agent. You bring your own.

Quick start

curl -fsSL https://github.com/edgestorage/task-handoff/releases/latest/download/install-server.sh | sudo sh

Repo: https://github.com/edgestorage/task-handoff
Docs: https://docs.thandoff.com/

Honest caveats

TaskHandoff is not yet a product that competes with Codex Desktop on polish. There's no floating
animated dog, no voice, none of that carefully finished desktop feel. It works on the layer underneath —
how tasks, machines, sessions and credentials get seen and connected.

If what you want is a beautiful integrated desktop experience, Codex Desktop is genuinely better at it
right now. The author of that post made exactly that trade, and it's a reasonable one.

TaskHandoff is also still Beta — the README says plainly that breaking changes may land between releases.

Paseo or TaskHandoff? The answer depends on where the code actually runs

TaskHandoff — Sun, 11 Oct 2026 16:21:03 +0000

If you go looking for an open-source way to run coding agents anywhere, you'll probably hit two projects in
the same afternoon: Paseo and TaskHandoff.

They look almost identical from the outside. Both are open source. Both connect desktop and phone. Both run
several agents at once. Both reach across more than one machine.

One difference separates them completely, and it fits in a sentence: where does the code actually run?

Let's be fair about Paseo first

Paseo is the current leader in this space: 20,000+ stars on GitHub, Apache-2.0, very active. It bills
itself as "orchestrate multiple coding agents from desktop and mobile," and it supports seven providers —
Claude Code, Codex, Copilot, OpenCode, Pi, Antigravity, and Muse Code. It also has voice control, a plugin
registry, schedules, and a built-in browser.

Architecturally, it runs a daemon on your machine, and the desktop app, mobile apps, web UI and CLI all
connect to that daemon.

And one line in its own README explains everything that follows:

"Agents run on your machine with your full dev environment. Use your tools, your configs, and your skills."

Paseo does ship a Docker image — but that image runs the daemon and its web UI, not your sessions. The
docs are explicit: the image does not bundle agent CLIs; you add those with your own child image.

So Paseo's default assumption is: this machine is mine, this environment is trusted, let the agent use it
directly. Most of the time, that assumption is correct. And it's exactly why Paseo feels so smooth — all
your config, all your skills, all your tooling, right there.

TaskHandoff starts from the opposite assumption

TaskHandoff is also an open-source (Apache-2.0) control plane, but it assumes:

this code might not be something you trust.

So it's built in three layers:

Control Plane        ← the console you look at
     ↓
  Node Agent         ← one per machine
     ↓
Controlled Instance  ← one isolated container per session

Every session runs in its own container, not directly on the host. That single choice cascades into
everything below.

So how do you actually choose?

If you want to give the agent full access → TaskHandoff

Here's the Codex help text for --dangerously-bypass-approvals-and-sandbox:

"EXTREMELY DANGEROUS. Intended solely for running in environments that are externally sandboxed."

Those last four words are the whole argument. Turning approvals off on your own laptop is genuinely
reckless. Turning them off inside a container you'll delete is the documented, intended use.

Paseo's default deployment is "agents on your machine, with your full dev environment." That's great — but it
means the boundary is your host, so you keep the approvals and you keep getting interrupted. If what you
want is "no interruptions, and no worry," you need the container.

If the code isn't yours → TaskHandoff

AI-generated code, a third-party PR, a script a customer handed you. None of that should get full access to
your machine.

If you have multiple customers or identities → TaskHandoff

TaskHandoff has an actual model for Git credentials. They're scoped to a remote (scheme + host + port +
repository path prefix). Secrets are write-only after saving. HTTPS tokens exist only for the duration of a
single credential-helper request. SSH private keys never leave the Node Agent — instances get a public
identity plus a signing proxy, and trust-on-first-use isn't allowed at all. A credential authorizes only the
initial clone unless you explicitly retain it on that instance.

When you're juggling several customers, that layer matters far more than raw speed.

If the environment has to be reproducible → TaskHandoff

TaskHandoff has environment templates: take a working container, commit it into a reusable template, and
every new instance starts from that same environment. Instead of "it happens to work on my machine."

And when is Paseo the better choice?

Let's just say it:

You want to run several agents on your own laptop, and you want voice, a plugin registry, and a more polished mobile app.
Your project only ever lives on your machine, and you don't need a boundary around the code.

Then Paseo is the better choice — and it's more mature, with a much bigger community. Pretending
otherwise would be silly.

The one-line version

Paseo puts the agent on your machine. TaskHandoff puts the agent in a box.

Both are right. It depends on whether you trust the code.

Quick start

curl -fsSL https://github.com/edgestorage/task-handoff/releases/latest/download/install-server.sh | sudo sh

Repo: https://github.com/edgestorage/task-handoff
Docs: https://docs.thandoff.com/

Honest caveats

TaskHandoff has single-digit stars and is in Beta — the README says plainly that breaking changes may land
between releases. Its provider support is nowhere near Paseo's. It's a smaller, more focused, more cautious
tool, not a bigger one.

If you're picking between two strong options, pick using the four cases above — not the star count.

Stop approving every command: put your AI agent in a container

TaskHandoff — Sat, 10 Oct 2026 22:03:33 +0000

If you've used a coding agent for more than a day, you know the rhythm.

It writes a command. It stops. It asks you to approve. You click yes.
It writes another command. It stops. It asks again.

By lunchtime you've clicked yes forty times, and you've quietly stopped reading what you're approving. At
that point the safety feature isn't protecting anything. It's just slowing you down.

There's a way to get the safety without the clicking, and it isn't a setting. It's where you run the agent.

What the approval prompt is really for

The prompt exists for one reason: the agent is about to run real code on your real computer.

Your SSH keys are on that computer. Your cloud credentials are on that computer. Six months of
uncommitted work is on that computer.

So the real question the prompt is asking you is: "Do you trust this command enough to let it run
**here?"

On your laptop, that's a great question.

Inside a container you can delete with one click, it's a question with no stakes.

Codex already ships the answer

Codex gives you three settings for exactly this. Straight from codex --help:

--ask-for-approval never — stop asking me
--approve-for-me — have a second AI review it instead of me
--dangerously-bypass-approvals-and-sandbox — turn off both the asking and the sandbox

That last one sounds like a bad idea, and the help text agrees with you. It says, in capitals:
EXTREMELY DANGEROUS.

But read the rest of the sentence:

EXTREMELY DANGEROUS. Intended solely for running in environments that are externally sandboxed.

Read that twice, because it's the whole point.

The person who wrote that flag isn't warning you away from it. They're telling you when to use it:
when the environment is already contained. Your laptop is not contained. A container is.

Same flag, completely different meaning, depending on which box it runs in.

Why "just turn them off" never felt safe

Because on your laptop, you're right not to. And if you've tried to make the prompts behave, you've
probably run into one of these:

You allow a folder, and it still isn't trusted, even with the bypass flag on (#14345).
"Allow for this session" is forgotten the moment you restart (#4212).
You turn on Full Access, and it still asks anyway (#29235, #28988).
Ordinary commands ask for approval in sandbox mode, so the sandbox does nothing but nag (#3140).
Your MCP tools ask on every single call (#16911).

These aren't rare edge cases. The best-known thread on the topic has 77 comments and the title
"Unusable on Windows due to permission ask for every shell command"
(#2860).

The pattern is always the same: the prompts are annoying when they work, and broken when you try to
turn them off. That's not a bug in Codex. That's what happens when you put a security gate on a machine
that isn't designed to be a security boundary.

The middle option, if "off" feels too far

If you're not ready to go fully unattended, there's --approve-for-me. Instead of asking you, Codex asks
another model to review the command and lets the boring ones through automatically. Only the genuinely
weird stuff reaches you. (Internally this is the "guardian" reviewer, and it's a stable feature —
guardian_approval shows up in codex features list.)

It's a fair trade, but be honest about what it costs: every decision is another model call. You're
spending tokens so that you don't have to look. That's often worth it. It's just not free.

A container changes what all of this costs

Here's the same three settings, inside a disposable container:

Setting	On your laptop	In a container
Ask me every time	safe, but exhausting	pointless — you'd be approving things that can't hurt you
Review with AI	a reasonable middle ground	fine, but you're paying for protection you mostly don't need
Never ask	reckless	the documented, intended use

Once the box is disposable, "never ask" stops being a dare and starts being the sensible default. You
get no prompts, no waiting, and none of those loops where you say no, the agent re-plans, you say yes
anyway — and pay for all of it in tokens
(#14593 has 630 comments about exactly that kind of waste).

So the order of decisions matters:

First choose how much damage one bad command can do. Then choose how much freedom to give the agent.

Do it the other way around and your only two options are "too noisy" and "too risky."

What TaskHandoff does

TaskHandoff is an open-source (Apache-2.0) control plane for running AI/Codex workspaces across your
own machines. Every session runs inside a managed Linux Docker container that you create, start, stop
and throw away from one console.

That container is the "externally sandboxed environment" from the help text.

Sessions run in a managed container, not on your desktop.
Workspaces are things you own and control: create, snapshot, restore, delete, rebuild.
Templates save a working toolchain once, so you don't rebuild it per project.
Multiple machines, one console — run the heavy work on a Linux box and drive it from your laptop.
Live session view over WebSocket.

You don't have to talk yourself into turning the prompts off. You just have to run the command somewhere
that was meant to be thrown away.

Quick start

curl -fsSL https://github.com/edgestorage/task-handoff/releases/latest/download/install-server.sh | sudo sh

Comes as a desktop app and a server (systemd on Debian/Ubuntu), with an English and Chinese UI.

Repo: https://github.com/edgestorage/task-handoff
Docs: https://docs.thandoff.com/

One honest caveat

Full access means the container is now the thing keeping you safe — so it has to really be disposable.
Don't mount the only copy of your credentials into it, and don't use it as a password vault.

And if your task genuinely needs your host machine, or Windows-only tools, keep the prompts on. These
three settings aren't a religion. They're just tools, and now you know which one matches which box.

Codex on Windows keeps fighting PowerShell — run it in a Linux container instead

TaskHandoff — Sat, 10 Oct 2026 17:17:29 +0000

If you run a coding agent on Windows for long enough, you'll notice a pattern: the agent writes a shell
command, it fails, it rewrites the command, it fails again — three or four times — and only then finds
something that works. On macOS or Linux the same task usually goes through on the first try.

It's tempting to blame the model. Usually it isn't the model. It's the shell layer underneath it.

What's actually happening

On native Windows, Codex doesn't hand your command to the OS as a plain argv list. External CLI
commands get wrapped and executed through PowerShell — closer to
pwsh.exe -Command "your-command ..." than a direct invocation
(#15294).

That single design decision cascades:

Quoting and escaping. PowerShell has its own quoting rules. A command that's perfectly valid in bash can need different escaping here — and the model has to guess which dialect it's writing for.
Permission rules stop matching. Because every command is rewritten into a PowerShell wrapper, allow-rules like "everything starting with dotnet" don't match reliably (#8537), which is why so many Windows users end up approving every single command (#2860, 77 comments).
Basic file operations go through the shell too. Even read/write/search were reported as PowerShell operations rather than internal tools (#3800).
Environment leaks. A child powershell.exe can inherit PowerShell 7's PSModulePath, which breaks module discovery and makes even Get-FileHash unavailable (#27117).
Sandboxing is flaky. Sandboxed PowerShell commands intermittently fail before the command even runs (#25497).
It's noisy. Every command can flash a console window (#48074, #48422).

The requests keep coming: people have asked, repeatedly, for a configurable Windows shell
(#16717, #31548,
#16579). Which tells you the community has already reached the
obvious conclusion: the shell layer is the problem, not the task.

The retry loop is what actually costs you

A failed command isn't just a wasted second. The agent has to reason about why it failed, produce a
different command, and try again — each round trip carries the whole context with it. On Windows this
can happen several times per task, and you pay for all of it in tokens and in your own attention.

The usual workarounds, and what they cost

WSL. Works, but now you maintain two environments, and the agent may or may not be running where your project actually lives.
Switch to Git Bash as the primary shell. Codex has been reported to chain Git Bash → PowerShell in confusing ways (#7298).
Approve everything. Fast, and exactly as bad an idea as it sounds.
Wait for a config option. Reasonable, but you're blocked on someone else's roadmap.

A different move: stop running your agent on Windows

TaskHandoff is an open-source control plane (Apache-2.0) for running and managing AI/Codex workspaces
across local and remote machines. Instead of fighting the host shell, each session runs inside a managed
Linux Docker workspace — and you drive it from one console.

Concretely, that means:

The agent always sees the same bash environment, whether the machine underneath is Windows, macOS, or Linux.
Docker workspaces are created, started, stopped and restored as first-class objects — no more "it worked on my other machine".
Environment templates let you snapshot a container's toolchain and reuse it, so a working setup doesn't have to be rediscovered per project.
Multi-node management puts local and remote machines on one board — run heavy work on a Linux box and still drive it from your Windows laptop.
AI session center streams session state in real time over WebSocket.

You don't need to teach the model PowerShell. You just stop asking it to.

Quick start

curl -fsSL https://github.com/edgestorage/task-handoff/releases/latest/download/install-server.sh | sudo sh

Ships as a Desktop app and a server (systemd on Debian/Ubuntu), with an English/Chinese UI.

Repo: https://github.com/edgestorage/task-handoff
Docs: https://docs.thandoff.com/

Honest caveats

Running your workspace in a container doesn't magically fix every Windows problem — if your project
genuinely needs Windows-only tooling, you'll want a Windows node. But for the large class of tasks where
the agent is looping on shell syntax and permissions, removing the host shell from the equation is the
cheapest fix available today.

TaskHandoff: one console for AI coding workspaces across local and remote machines

TaskHandoff — Sat, 10 Oct 2026 15:23:04 +0000

If you run AI coding sessions (Codex, agents, background jobs) for more than a few weeks, they start to sprawl. One session on the laptop, one on a home server, a couple inside Docker containers on a remote VM — and no single place that tells you what is running, where it lives, and how to hand it off.

TaskHandoff is an open-source control plane (Apache-2.0, TypeScript) that pulls those AI workspaces into one board. I've been using it to keep local and remote machines in the same view, and it's finally at a state worth sharing.

The problem

Once AI sessions spread across machines, you end up juggling:

SSH tabs, container shells, and a half-dozen config files
No shared view of "what's running where"
Rebuilding the same container toolchain over and over
Copy-pasting context between a chat app and the machine that actually does the work

What it does

Multi-node management — local and remote machines in a single board
Managed Docker workspaces — create, run, and restore workspaces as first-class objects
Environment templates — snapshot a container's tools + config and reuse it elsewhere
AI session center — real-time sessions over WebSocket, attach/detach at will
Repository workflows — files, changes, branches, and git worktrees from the UI
Scoped Git credentials — hand each workspace only the credentials it needs
Chat integrations — route tasks from Telegram, DingTalk, WeChat, or Lark
App catalog + mobile client — plus a Desktop app and a server, with an English/Chinese UI

Quick start

curl -fsSL https://github.com/edgestorage/task-handoff/releases/latest/download/install-server.sh | sudo sh

Ships as a Desktop client and a server (systemd on Debian/Ubuntu). Once the server is up, open the console and add your machines.

Why it exists

Most AI tooling optimizes the model. TaskHandoff optimizes the plumbing — the boring, error-prone part of running those models somewhere real, across more than one box, without losing track of your sessions.

DEV Community: TaskHandoff

Where did I leave that? Managing AI agent sessions across machines

See if any of this is you

This is now an entire product category

All of those tools hit the same ceiling

TaskHandoff organizes sessions around an idea called Story

Quick start

The line worth ending on

Honest caveats

You can build your own Codex Desktop. The glue is the hard part.

He pulled it off. Then he went back to Codex Desktop.

What he was actually staying for

The open-source gap was never the agent

That's the seat TaskHandoff takes

Quick start

Honest caveats

Paseo or TaskHandoff? The answer depends on where the code actually runs

Let's be fair about Paseo first

TaskHandoff starts from the opposite assumption

So how do you actually choose?

If you want to give the agent full access → TaskHandoff

If the code isn't yours → TaskHandoff

If you have multiple customers or identities → TaskHandoff

If the environment has to be reproducible → TaskHandoff

And when is Paseo the better choice?

The one-line version

Quick start

Honest caveats

Stop approving every command: put your AI agent in a container

What the approval prompt is really for

Codex already ships the answer

Why "just turn them off" never felt safe

The middle option, if "off" feels too far

A container changes what all of this costs

What TaskHandoff does

Quick start

One honest caveat

Codex on Windows keeps fighting PowerShell — run it in a Linux container instead

What's actually happening

The retry loop is what actually costs you

The usual workarounds, and what they cost

A different move: stop running your agent on Windows

Quick start

Honest caveats

TaskHandoff: one console for AI coding workspaces across local and remote machines

The problem

What it does

Quick start

Why it exists

Links