DEV Community: CodeKing

"My Coding Agent Remembered Sessions, Not Work. That Was the Bug"

CodeKing — Fri, 03 Jul 2026 08:26:28 +0000

A coding agent can keep a thread alive and still feel forgetful.

That was the annoying part I ran into after fixing session continuity in CliGate, my local control plane for a resident assistant, Claude Code, Codex CLI, model routing, channels, and scheduled work.

The session was there. The follow-up worked. But repeated tasks were still slower than they should have been.

Why?

Because the agent remembered the conversation, not the work.

A live session is not the same thing as usable memory

Session continuity solves one real problem.

It keeps follow-ups like these from turning into a fresh start:

continue
do the same for this file
retry that
explain the error

That matters.

But it does not solve another problem that shows up the second you repeat a workflow a few days later.

If the agent previously figured out:

which button actually works
which step is a dead end
which field needs special handling
which rule the user always wants applied

then a still-open session is not enough.

The useful thing is not that the thread exists.

The useful thing is that the agent can recall what made the last run succeed.

The bug was “process amnesia”

The first run usually contains the expensive part.

That is when the agent explores, verifies, backtracks, and discovers the tiny details that are never in the idealized prompt:

this page hides the action under a menu
this editor is actually an iframe
this project wants Chinese replies and concise status updates
this environment URL is different from production

Before I fixed this in CliGate, those details existed only as raw execution history.

That meant the agent technically had logs, but not reusable memory.

On the next similar task, it often had to rediscover too much.

That is not intelligence.

That is paying the same debugging cost twice.

I stopped treating memory like a chat transcript problem

The wrong model was:

save more history -> keep more context -> hope the next run uses it well

That helps a little, but it gets noisy fast.

What I actually needed was a smaller, more reusable layer:

procedures
facts
directives
references

In other words, not “everything that happened,” but “what should be remembered from what happened.”

That changed the shape of the system.

Instead of forcing the next run to infer the lesson from a giant transcript, the assistant now has a file-based memory layer that can recall:

a procedure: the current best steps and known dead ends
a fact: a URL, environment rule, or known setting
a directive: how the user wants things done
a reference: where the relevant doc lives

That is much closer to how people actually work.

The important rule was verify-then-trust

The trap with workflow memory is obvious.

Interfaces change.

Buttons move.

Old steps decay.

So I did not want “perfect replay.”

I wanted something closer to this:

recall the previous best procedure
-> try it first
-> verify each important step
-> if it no longer works, fall back to exploration
-> update the memory after success

That turned out to be the difference between brittle automation and useful operational memory.

A remembered workflow should save exploration, not replace judgment.

This also fixed a second problem: user rules kept getting lost in the noise

There is another kind of “memory” that does not belong in a runtime session at all.

Things like:

always reply in Chinese
keep answers concise
do not touch production data
this project uses this test environment

Those are not just follow-up context.

They are standing operating rules.

Once I separated those from ordinary conversation history, the assistant became much more predictable.

The model no longer had to rediscover the same user preference in the middle of a task. It could start from it.

That sounds small, but it reduces a lot of friction.

The real improvement was skipping re-discovery

The best sign that this change mattered was not that the memory layer looked elegant.

It was that repeat tasks got shorter.

The assistant could move faster because it was no longer starting with an empty tactical model every time.

Instead of:

inspect again
guess again
retry again
rediscover the same dead end

it could do this:

recall the best-known path
verify it
continue from there

That is a better loop for both desktop-style workflows and non-desktop tasks.

And it scales better than pretending one long-lived session can stand in for real memory.

The rule I am keeping

If you are building a coding agent, do not confuse “the thread is still attached” with “the system learned something useful.”

A session helps with continuity.

Memory helps with repeated work.

Those are different layers.

The session should keep the conversation alive.

The memory layer should keep the useful lessons alive.

Once I separated those two, CliGate started feeling less like a chat system with a very long buffer and more like an assistant that can actually learn how work gets done.

If you are building agent workflows, is your system remembering the thread, or remembering the successful procedure?

Three habits that make AI coding agents actually useful

CodeKing — Wed, 01 Jul 2026 13:46:42 +0000

Most of the friction people hit with AI coding agents isn't the model — it's how we hand work to it. After pairing with agents daily for months, three small habits have made the biggest difference for me.

1. Give the agent a way to verify itself

An agent that can run the tests, read the output, and try again is worth far more than one that only emits code. Before asking for a change, make sure there's a command it can run to know whether it succeeded. "Make the test pass" beats "write this function" almost every time, because success becomes something the agent can check instead of something you have to.

2. Keep the task smaller than you think it should be

Large, vague asks produce large, vague diffs that are hard to review. Scoping a request to a single file or a single behavior keeps the change reviewable and the feedback loop tight. You can always chain small wins into a big one — but you can't easily un-tangle one sprawling change.

3. Write down the intent, not just the instruction

Telling an agent what to do gets you one result. Telling it why — the constraint you actually care about, the thing that must not break — lets it make the dozens of small decisions you never spelled out. Intent travels further than instructions.

None of this is tied to a particular tool. It's about treating the agent like a fast, literal collaborator that does its best work when the goal is concrete and checkable.

"My AI Assistant Stopped Working the Moment I Closed the Chat"

CodeKing — Tue, 30 Jun 2026 07:17:56 +0000

A lot of AI assistants only feel helpful while the chat window is still open.

You ask for something, watch it think, maybe answer one follow-up, and then you leave.

That is the moment the illusion breaks.

If the assistant cannot wake itself up later, run something in the background, and only come back to you when it actually needs you, it is not much of an assistant. It is just a chat box with good manners.

That was one of the more practical lessons while building CliGate, my local AI control plane for a resident assistant, scheduled work, channels, Claude Code, Codex, and model routing behind one localhost service.

The real bug was requiring the user to babysit the assistant

The old mental model was too chat-shaped.

A user message arrived. The assistant did some work. The answer came back into the same visible thread.

That works for interactive tasks, but it falls apart for the boring real ones:

send me a morning summary
publish a post tonight
check something while I am offline
keep going later and ping me only if you get stuck

In other words, the assistant needed a way to work without pretending the user was still sitting there.

A reminder was not enough

The first naive version of scheduled work is just:

at 8 PM -> send message

That is fine for "drink water" reminders.

It is useless for anything that needs actual reasoning or tools.

What I wanted instead was:

at 8 PM -> wake the assistant with an instruction
-> let it run in the background
-> send me the result
-> if it needs input, route my reply back into that paused run

That sounds small, but it changes what a scheduled task really is. It stops being a timer and starts being a delayed assistant run.

The assistant needed its own hidden workspace for each fire

One subtle bug showed up fast.

If every recurring run reused the same hidden conversation forever, the assistant started treating later fires like duplicates.

That is especially bad for recurring work. A scheduled publishing task should not say "already done" just because a previous run earlier that day used the same scope and saw similar history.

So I ended up separating two modes:

fresh context by default for recurring work
shared context only when explicitly useful

That means a recurring task can wake the assistant in its own background scope conversation, without polluting the user's visible chat and without inheriting the wrong assumptions from the last run.

In CliGate, that also made the scheduling model much easier to trust: each fire can be a clean round, while things like a running diary can still opt into shared context.

The tricky part was not starting the run. It was pausing honestly.

Background runs do not always finish cleanly.

Sometimes the assistant needs the user.

Maybe a credential is missing. Maybe a choice matters. Maybe a risky action needs confirmation.

If that happens inside a hidden scheduled-task scope, the run cannot just hang there forever.

So the assistant needed a bridge back to the user-facing conversation.

The model that finally felt right was:

scheduled run happens in a hidden scope conversation
visible conversations only get notifications
if the run pauses on the user, remember which scheduled task is waiting
when the user replies in the visible conversation, route that reply back to the paused background run

That was the difference between "background automation" and "a silent dead end."

The UI had to explain the tradeoff clearly

One thing I like about this setup is that the user-facing choice is simple.

A scheduled task can either:

notify user with a static message, or
invoke assistant with a real instruction

And when invoking the assistant, two more controls matter a lot:

optional working directory
whether runs share context or start fresh

That is enough surface area to be useful without turning scheduling into a mini workflow engine.

Most people do not want cron trivia. They want to say:

every morning, summarize this project
tonight, publish the draft
every weekday, check this thing and message me if it failed

That is the level an assistant should operate at.

The result was a more believable assistant

The biggest win was not technical elegance.

It was behavioral honesty.

The assistant no longer had to pretend every task was a live chat exchange.

Now it can:

wake up later
run unattended
keep background work out of the main conversation
push a result back when it is done
ask for help only when it actually needs help
continue from the user's reply instead of losing the thread

That made CliGate feel a lot less like "chat with extra steps" and a lot more like an actual local operator.

If you are building AI assistants, this is the line I would not blur: a scheduled reminder is not the same thing as a scheduled assistant run, and users feel the difference immediately.

"My Two AI Tasks Kept Fighting for the Same Mouse"

CodeKing — Sun, 21 Jun 2026 12:03:06 +0000

Parallel agent demos look great right up until two tasks both try to use the same mouse.

One task is logging into a site. Another one opens a browser window. A third thing is only supposed to answer a status question, but now the whole system is clicking in the wrong place, cancelling the wrong run, or reporting a failure that is really just resource contention.

That was one of the more useful reliability lessons while building CliGate, my local control plane for a resident assistant, Claude Code, Codex, channels, scheduled work, and desktop automation.

The real bug was not "parallelism"

Parallelism was fine.

The bug was pretending every task could use every resource at the same time.

Code tasks can run in parallel. A weather lookup can happen while a runtime session is still working. A background summary does not need to block anything.

But the desktop is different.

There is only one physical keyboard, one mouse, and one visible screen. If two agent runs both think they own that surface, the result is not intelligent multitasking. It is sabotage.

I first made the classic bad fix

My first instinct was the lazy one:

if a new task shows up and something else is already running, cancel the old run and let the new one take over.

That sounds simple. It is also wrong.

A user asking "how far did it get?" should not cancel a login flow. A user asking for the weather should not kill a desktop task. And the worst version of this bug is when an agent sees another active run and accidentally cancels itself.

That was the moment I stopped treating concurrency as a prompt problem.

It was a resource problem.

The fix was to separate task concurrency from resource ownership

The rule I wanted turned out to be much simpler than the behavior I had before:

independent tasks should run in parallel
tasks that need the desktop should queue
cancellation should only happen when the user clearly asks for it

That meant I needed the assistant to know something more concrete than "there are active runs."

It needed to know:

which run currently holds the desktop
whether the new request is only a status query
whether the new task can run without the desktop
whether the user is correcting the current task or replacing it

That sounds obvious in hindsight, but it changes the control flow a lot.

I ended up treating the desktop like a leased resource

In CliGate, desktop input is now handled more like a lease than a best-effort tool call.

A task that starts using the mouse and keyboard becomes the current desktop holder. Another task can still exist, but it does not get to click on top of the first one. It waits.

The mental model is closer to this:

new task arrives
-> does it need the desktop?
-> if no, run in parallel
-> if yes and desktop is free, acquire it
-> if yes and desktop is busy, queue it
-> only cancel when the user explicitly says stop

That was the missing boundary.

Before that, I had a lot of behavior that looked concurrent in logs but felt random to the user.

The queue mattered more than another retry loop

One of the subtle failures in desktop automation is that retries can make things worse.

If a second task keeps trying to grab the mouse while the first task is still typing or waiting for a window, more retries do not increase reliability. They just increase interference.

So the better fix was not:

retry the click harder
guess a different coordinate
keep asking the model what to do

The better fix was to make the assistant say the honest thing:

the desktop is busy, I am queued behind the current task, and I will start automatically when it is released

That turns a confusing failure into predictable behavior.

I also had to block the dumbest cancellation path

There was another bug hiding inside the same area.

If the assistant is allowed to cancel any active run it sees, it needs a hard rule against cancelling the run it is currently inside.

So I treated that as an invariant rather than a suggestion:

do not list the current run as a cancel target
reject self-cancel if it is somehow attempted anyway
check for cancellation continuously so cancelled runs actually stop cleanly

That part is not glamorous, but it is the difference between a trustworthy scheduler and an agent that panic-clicks its own off switch.

The UX got simpler once the system became less "smart"

This is the pattern I keep running into with agent tooling.

A lot of bad behavior comes from trying to be clever too early.

What users actually need is often plainer than that:

if a task does not conflict, let it run
if it conflicts over one physical resource, queue it
if the user asks for status, answer from status
if the user says stop, stop

That is less magical than a giant orchestration layer that tries to infer everything from every message.

It is also much easier to trust.

That resource-aware queue ended up making parallel agent work feel more human, not less. The assistant stopped acting like every incoming message was a fight for control, and started acting more like an operator that understands the difference between a question, a correction, and a second pair of hands trying to grab the same mouse.

If you are building AI tooling that touches the desktop, this is the part I would not fake: parallel tasks are fine, but physical resources still need ownership.

"I Stopped Pretending Every AI Provider Was the Same"

CodeKing — Sat, 20 Jun 2026 12:10:47 +0000

The easiest way to make an AI gateway feel flaky is to pretend every upstream model works the same way.

On paper, a lot of tools look compatible.

They all take a prompt. They all return text. Some of them even share an OpenAI-shaped API.

In practice, the differences show up exactly where users stop forgiving you:

a tool-specific field gets dropped
an image payload works on one route and breaks on another
a model switch silently changes behavior
the request succeeds, but the wrong capability set was assumed

That was one of the most useful lessons while building CliGate, my local control plane for Claude Code, Codex CLI, Gemini CLI, OpenClaw, a resident assistant, and multiple model/account sources behind one localhost entrypoint.

The bug was not “routing failed”

The bug was subtler than that.

Routing often did succeed. A request got sent somewhere. A response came back. Nothing obviously crashed.

But that did not mean the gateway was correct.

If you route different tools and providers as if they were interchangeable, you get a class of failures that are hard to spot from logs alone:

Claude-style payloads that need translation, not passthrough
Codex-compatible flows that should degrade unsupported fields instead of forwarding them blindly
Gemini paths that need their own capability assumptions
local or fallback routes that are reachable but not feature-equivalent

That is not just transport routing.

That is capability routing.

I had to separate “where to send it” from “what this destination can really do”

At first, it is tempting to think routing is just:

pick provider -> send request

That model is too small.

What actually mattered in CliGate was closer to this:

identify caller/tool
-> identify protocol shape
-> resolve provider/model source
-> apply capability profile
-> translate or degrade fields safely
-> send upstream

A provider being reachable is not enough.

It also needs to be treated according to the features it really supports.

Translation turned out to be part of routing

One of the more useful internal lessons in this project is that protocol translation is not a separate cleanup step after routing.

It is part of routing.

Some paths can accept a richer request shape. Some need fields normalized or stripped before the request becomes a silent bug.

That changed the safe mental model from:

“upstream did not complain, so the route must be fine.”

to:

“this route supports a specific capability profile, so normalize on purpose.”

That sounds small, but it prevents a lot of “works sometimes” behavior.

A “compatible API” is not the same thing as compatible behavior

This is the trap.

Lots of systems advertise compatibility because they accept a familiar endpoint shape.

But compatibility at the HTTP layer is only the beginning.

If one tool expects richer reasoning or metadata semantics and another backend treats those fields differently, the gateway has three bad choices:

pass everything through and let undefined behavior happen
reject too aggressively and feel brittle
normalize by capability and keep behavior predictable

Only the third one scales.

That is why I now prefer capability-aware routing over a universal passthrough design.

Caller identity matters more than I expected

claude-code, codex, gemini-cli, openclaw, and generic OpenAI/Anthropic-compatible clients may hit similar-looking routes, but they are not interchangeable from an operator’s perspective.

The user is often really asking for one of these:

keep Claude Code on the provider/model path that fits Claude-style flows
bind Codex to a specific account or key
let Gemini use its own capability profile
fall back safely when a source is unavailable

That is why app-aware routing and capability-aware translation ended up being complementary, not separate concerns.

One decides who this request is for.

The other decides how to make it truthful on the way through.

Degrade intentionally, never accidentally

The worst failures are the accidental ones.

If a gateway quietly forwards a field that the destination ignores, the user may never know why results became inconsistent.

So I started preferring explicit degradation rules.

If a route cannot honor a field, normalize it on purpose.

If a provider cannot match a capability, map it honestly.

If a model source is rate-limited or invalid, skip it instead of pretending all active-looking credentials are equal.

That gives me a much better operator story:

why this source was chosen
which capability profile was applied
which fields were transformed or removed
why a different route would behave differently

Reliability improved when I stopped chasing “perfect abstraction”

A good gateway should hide repetitive setup work.

It should not lie about capability differences.

Once I accepted that, the architecture became cleaner:

route by app and protocol
map by provider/model source
translate by capability profile
expose the differences clearly in logs and settings

That is less magical, but much more dependable.

The rules I would keep

If I were designing another AI gateway tomorrow, I would keep these rules:

do not equate API shape with feature equivalence
make caller identity a first-class routing input
treat translation as part of routing
degrade unsupported fields deliberately
expose capability decisions so operators can explain failures

That is the direction I have been pushing with CliGate.

The project still aims to give me one local place for model routing, accounts, API keys, local runtimes, channels, runtime sessions, and an assistant layer.

But the system became much more trustworthy once I stopped pretending every upstream provider was the same.

If you run multiple AI tools through one gateway, are you doing plain endpoint routing, or routing by actual capability too?

"My Two AI Tasks Kept Fighting for the Same Mouse"

CodeKing — Thu, 18 Jun 2026 12:01:22 +0000

The second my local AI assistant learned how to operate Windows apps, I ran into a new bug.

Not a model bug. Not a prompt bug.

A traffic bug.

One task was logging into a site through the desktop. Another task wanted to open a different app. Both requests were valid. Both were "in progress." And both were trying to use the same physical mouse, keyboard, and screen.

That is when an assistant stops feeling like software and starts feeling like two interns fighting over one laptop.

The first version knew there were multiple runs, but not one shared desktop

In CliGate, I already had the shape of a resident assistant: background runs, task records, channel conversations, runtime delegation, and desktop automation on Windows.

The problem was that "multiple tasks" and "multiple desktop tasks" are not the same thing.

Most work can run in parallel just fine. A coding task can edit files while another task checks the weather or summarizes a document. But desktop control is a physical boundary. There is only one active pointer, one focused window, one keyboard target.

If the system treats every run as equally parallel, desktop tasks do not feel concurrent. They feel destructive.

One can steal focus. Another can click into the wrong window. A third can decide there is already a similar run and cancel the wrong thing entirely.

The bug was confusing activity with resource ownership

The old mental model was too shallow:

conversation -> active runs -> decide whether to cancel one

That can work for status displays. It is not enough for desktop scheduling.

What I actually needed was a separate truth the assistant could look at:

resource: desktop
holder: run X
waiters: run Y, run Z

That changed the question from:

"Are there other active runs?"

into:

"Is the desktop currently held by another run, and if so should this task wait, answer from state, or be cancelled because the user explicitly said stop?"

That is a much more useful question.

The fix was resource-aware scheduling, not blanket cancellation

I ended up moving toward a simple rule set.

If two tasks do not need the same exclusive resource, let them run in parallel.

If they both need the desktop, serialize them.

If the user asks for status, answer from the existing run instead of touching the desktop again.

If the user says "stop," cancel the target run explicitly.

That sounds obvious in hindsight, but it changed the behavior a lot.

Instead of seeing another run and trying to kill it, the assistant can now treat the desktop like a queueable resource. One task holds it. The next desktop task waits. When the holder finishes, the next one starts automatically.

That is much closer to how a human assistant would behave. You would not cancel a login flow just because someone also asked you to open another app. You would say: "I'm in the middle of this one, I'll do the next desktop step right after."

It also cleaned up the UX around interruption

The nice side effect is that the assistant becomes easier to talk to during long tasks.

While a desktop job is running, I can still ask:

what happened to the last run?
how much is left?
can you also write a script in the repo?

Those should not all be treated as reasons to interrupt the desktop flow.

The assistant can answer status questions from run state, do non-desktop work in parallel, and only queue the things that truly need the same physical controls.

That made the product feel less like a brittle automation demo and more like an actual operator with limited hands.

The rule I am keeping

If an agent can touch the real desktop, it needs to understand the difference between:

parallel work
exclusive resources
explicit cancellation
simple status follow-ups

Without that split, concurrency just becomes another word for collision.

That is now part of how I am shaping CliGate, the local control plane I use for Claude Code, Codex CLI, Gemini CLI, channels, desktop automation, and a resident assistant layer on top.

The project is open source here: CliGate.

If you are building local agents, are you treating the desktop as just another tool call, or as a resource that needs scheduling?

"My Coding Agent Finished the Task. Why Did the Thread Die?"

CodeKing — Wed, 17 Jun 2026 12:02:51 +0000

The most annoying follow-up bug in a coding agent is not a crash.

It is when the first task succeeds, and the next message still feels like amnesia.

I would ask Claude Code or Codex to do something through my local assistant, wait for it to finish, and then send the most normal follow-up in the world:

make the button green

From the user's side, that is obviously part of the same thread.

From the system side, it was too easy to treat completed as "this session is over, start from scratch next time."

That was the bug.

The real problem was mixing up three different things

While building CliGate, I realized I had let three layers blur together:

the chat conversation
the runtime session
the current execution turn

Those are not the same object.

A conversation is the long-lived place where the user keeps talking.

A runtime session is the working thread attached to that conversation.

A turn is just one run inside that session.

Once I wrote it down that way, the mistake became obvious. completed should mean the current turn is done. It should not mean the whole thread has to be detached.

Why the old behavior felt wrong so quickly

The broken flow looked like this:

user asks for task
-> runtime session starts
-> task completes
-> conversation clears active session
-> next follow-up starts a brand-new session

That does not sound terrible until you use it from a phone or a busy web chat.

Real follow-ups are short. People say things like:

retry that
do the same for this file
make the button green
explain the error
continue

Those messages only work if the agent still knows what thread they belong to.

If the system detaches the session the second one task finishes, the user is forced back into full restatement mode. The agent technically works, but the thread feels fake.

The fix was not more prompting

My first instinct was to improve follow-up classification.

That helped a little, but it was not the core fix.

The real fix was to make the binding model explicit:

conversation is persistent
runtime session is sticky by default
completed/failed only close the current turn
a new session should be explicit, or caused by a real compatibility change

In other words, I stopped treating task completion as session death.

That tiny semantic change affects the whole product feel.

When should a new session actually start?

Not every follow-up should reuse the old session forever.

But the boundary needs to be meaningful.

In CliGate, the cases that justify a new session are things like:

there is no bound session yet
the user explicitly asks for a new one
the provider or model changed in a way that makes reuse incompatible

That is very different from saying the last turn completed, so the thread should be thrown away.

The first rule matches how people think.

The second rule matches how brittle plumbing thinks.

This mattered on both web chat and mobile channels

The nice part is that the same model applies in more than one place.

In a web chat window, the user expects one tab to behave like one ongoing thread.

In Telegram, Feishu, or DingTalk, the expectation is even stronger. A conversation on the phone is already compressed. The user is relying on the system to preserve context across tiny, vague follow-ups.

So the product behavior I wanted was simple:

first message creates a runtime session
later messages keep using that session by default
completed or failed do not silently drop the thread
/new or a real config drift can start a fresh session

That makes the agent feel much closer to a real working thread instead of a command launcher.

The subtle UX win was explaining the boundary clearly

Once you separate conversation, session, and turn, the UI gets easier to reason about too.

The user can understand:

this conversation is still attached to a session
the last turn is done
I can keep asking follow-ups
if I want a clean start, I should explicitly ask for a new session

That is a much better mental model than making the user guess whether the tool still remembers anything.

It also makes debugging easier. If a new session appears, it should be because the user asked for one or because something important changed, not because the state machine quietly treated success as disposal.

The rule I am keeping

If you are building a coding agent, do not let one successful task kill the thread.

The durable unit is the conversation.

The reusable worker is the runtime session.

The thing that ends on success or failure is the turn.

Once I separated those three layers, follow-ups stopped feeling random and started feeling conversational.

That is now part of how I am shaping CliGate, the local control plane I use for Claude Code, Codex CLI, Gemini CLI, channels, and a resident assistant layer on top.

If you are building agent workflows, are you treating completion as the end of a turn, or the end of the whole thread?

"My Two AI Tasks Kept Fighting for the Same Mouse"

CodeKing — Tue, 16 Jun 2026 12:02:21 +0000

The second my local AI assistant learned how to operate Windows apps, I ran into a new bug.

Not a model bug. Not a prompt bug.

A traffic bug.

That is when an assistant stops feeling like software and starts feeling like two interns fighting over one laptop.

The first version knew there were multiple runs, but not one shared desktop

In CliGate, I already had the shape of a resident assistant: background runs, task records, channel conversations, runtime delegation, and desktop automation on Windows.

The problem was that "multiple tasks" and "multiple desktop tasks" are not the same thing.

If the system treats every run as equally parallel, desktop tasks do not feel concurrent. They feel destructive.

One can steal focus. Another can click into the wrong window. A third can decide there is already a similar run and cancel the wrong thing entirely.

The bug was confusing activity with resource ownership

The old mental model was too shallow:

conversation -> active runs -> decide whether to cancel one

That can work for status displays. It is not enough for desktop scheduling.

What I actually needed was a separate truth the assistant could look at:

resource: desktop
holder: run X
waiters: run Y, run Z

That changed the question from:

"Are there other active runs?"

into:

"Is the desktop currently held by another run, and if so should this task wait, answer from state, or be cancelled because the user explicitly said stop?"

That is a much more useful question.

The fix was resource-aware scheduling, not blanket cancellation

I ended up moving toward a simple rule set.

If two tasks do not need the same exclusive resource, let them run in parallel.

If they both need the desktop, serialize them.

If the user asks for status, answer from the existing run instead of touching the desktop again.

If the user says "stop," cancel the target run explicitly.

That sounds obvious in hindsight, but it changed the behavior a lot.

It also cleaned up the UX around interruption

The nice side effect is that the assistant becomes easier to talk to during long tasks.

While a desktop job is running, I can still ask:

what happened to the last run?
how much is left?
can you also write a script in the repo?

Those should not all be treated as reasons to interrupt the desktop flow.

The assistant can answer status questions from run state, do non-desktop work in parallel, and only queue the things that truly need the same physical controls.

That made the product feel less like a brittle automation demo and more like an actual operator with limited hands.

The rule I am keeping

If an agent can touch the real desktop, it needs to understand the difference between:

parallel work
exclusive resources
explicit cancellation
simple status follow-ups

Without that split, concurrency just becomes another word for collision.

That is now part of how I am shaping CliGate, the local control plane I use for Claude Code, Codex CLI, Gemini CLI, channels, desktop automation, and a resident assistant layer on top.

The project is open source here: CliGate.

If you are building local agents, are you treating the desktop as just another tool call, or as a resource that needs scheduling?

My Coding Agent Asked Permission for Every Tiny Step

CodeKing — Tue, 16 Jun 2026 07:48:24 +0000

The most annoying bug in my local AI assistant was not that it refused to ask for permission.

It was that it asked too often.

I would give it a normal task like "read this PDF and tell me what is inside." The assistant would make a reasonable first move, ask for approval, run the command, and then immediately ask again for the next tiny probe.

One task turned into a permission treadmill.

The approval loop felt safe but unusable

Approval prompts are good. I want a local assistant to stop before it runs commands, writes files, opens apps, or touches the desktop.

The problem is that real work is rarely one tool call.

Reading a PDF might require checking whether Python exists, finding a converter, running the converter, reading the text output, and then summarizing it. A desktop task might require focusing a window, entering text, pressing a button, and verifying the result.

If every step asks the same kind of question, the user stops evaluating risk and starts clicking through interruptions.

That is worse than unsafe. It trains the user to ignore the safety system.

The bug was treating approval as a single event

The old flow in CliGate looked roughly like this:

assistant chooses tool
-> policy says confirmation required
-> user approves
-> tool runs
-> assistant continues
-> next tool asks again

That was technically correct. Each tool call had its own confirmation.

But it missed the shape of the user's intent. The user was not approving "run one tiny probe." They were approving the assistant to continue one bounded task.

So I changed the behavior after the first approved action in a chat conversation.

Once the user approves the first execution tool for the task, CliGate flips a conversation flag that lets later steps continue without another approval roundtrip. The assistant still feeds the real tool result back into the continuation run, so it can keep working from what actually happened instead of pretending the approval itself completed the task.

The escape hatch matters too:

/safe

That turns the conversation back into explicit confirmation mode.

The continuation had to carry the real result

There was another subtle part.

When a user approves a pending action, the system cannot just say "confirmed" and stop. It has to continue the original job.

The continuation prompt now tells the assistant that the previous tool call was approved, already executed, and produced a real result. That stops the assistant from asking for the same approval again or forgetting why the tool ran in the first place.

This made the assistant feel much less like a form with a chatbot attached to it. The flow became:

ask once for the risky boundary
execute the first step
continue the task with real observations
only interrupt again when the user explicitly returns to safe mode or a genuinely different boundary appears

The interesting part is that the fix is not "disable approvals." It is "remember what approval was for."

I also hit a language bug

This same continuation path exposed a smaller but very visible bug.

The continuation message was system-generated and written in English. When the original user task was Chinese, the assistant sometimes detected the system continuation as the latest "user" text and switched the next confirmation prompt to English.

That produced an ugly mixed-language workflow: first approval in Chinese, later approval prompts in English.

The fix was simple in principle: system-authored continuation turns should not decide the reply language. The assistant now looks back to the latest genuine user message in the conversation before choosing the response language.

That is the kind of detail that seems minor until you use the tool for a multi-step task. Then it is the difference between "this assistant is tracking me" and "this assistant is reacting to its own plumbing."

The rule I am keeping

I do not think agent approval should be all-or-nothing.

For local tools, the useful middle ground is task-scoped trust:

ask before crossing a meaningful boundary
remember that approval for the current task
keep an obvious way to return to strict mode
do not let system continuation messages masquerade as user intent

That is now how I am shaping approvals in CliGate, the local control plane I use for Claude Code, Codex CLI, Gemini CLI, desktop automation, channels, and model routing.

The project is open source here: CliGate.

If you are building local agents, how are you handling approval fatigue: per tool call, per task, per session, or something more granular?

"I Added a /yolo Button to My Local AI Assistant"

CodeKing — Mon, 15 Jun 2026 09:32:38 +0000

I like local AI assistants that ask before they do risky things.

I do not like approving the same task six times in a row.

That was the failure mode I kept hitting while working on CliGate. A normal task would start with one reasonable command, then another, then another, and every tiny step wanted a fresh confirmation.

So I added a blunt but useful switch:

/yolo

It sounds reckless, but the real goal was the opposite: make the assistant feel faster without training me to click through meaningless approval spam.

The bad version of safety was too chatty

The old loop looked safe on paper:

assistant picks a mutating tool
-> asks for confirmation
-> user approves
-> one tool runs
-> assistant continues
-> next tiny tool asks again

That is technically correct.

It is also miserable in practice.

A real task is rarely one tool call. Reading a document, checking a project, or sending a result through a channel usually means several small steps in a row. If every step interrupts the user, the approval system stops communicating risk and starts communicating friction.

That is when safety UI turns into background noise.

/yolo made the approval scope match the user's intent

The fix was not "remove approvals." It was "remember what the user actually meant."

In CliGate, /yolo flips a conversation-level flag:

later mutating tool calls in the same conversation auto-approve
the assistant stops asking for every tiny follow-up step
the user can turn strict mode back on with /safe

Under the hood, the flag lives on the conversation metadata as assistantCore.autoApproveTools, and both web chat and channel conversations read the same source of truth.

That detail mattered because I did not want one behavior in the web UI and a different one in DingTalk or Feishu.

Natural language mattered as much as the slash command

The more interesting part is that users do not always type /yolo.

They say things like:

"后续都同意"
"不要再问我了"
"直接执行"
"from now on, just do it"

So I added sticky-approval phrase detection too.

That means the assistant can recognize conversation-wide consent from normal language, not only from a command. But it still treats denial phrases separately, so "我不同意" does not accidentally enable auto-approve just because it contains the word "同意".

This turned out to be one of those small pieces of product logic that matters more than the model prompt.

I still kept a real high-risk boundary

The trap with a feature named /yolo is obvious: if everything gets auto-approved, then safety is fake.

So I kept one hard rule.

Routine local work can flow through auto-approve mode, but genuinely destructive or external actions still need a fresh explicit confirmation.

That means things like:

deleting files or directories
overwriting data in a destructive way
publishing outward
sending messages to other people or other conversations
submitting forms

still stop and ask.

That boundary is what makes the mode usable. The assistant can stop being noisy about low-level execution steps while still pausing when the consequence is actually irreversible or external.

One confirmation can now cover a whole batch

I also found a second bug while fixing this.

Sometimes one pending confirmation represented multiple queued tool calls. Historically, approving it only executed the first one, which silently dropped the rest.

The confirmation service now expands a pending action into all captured tool invocations and runs each of them in order. One approve means the whole batch gets executed, not just item one.

That sounds like an implementation detail, but it changes user trust a lot. If the UI says "confirmed," users expect the intended action to finish, not partially disappear.

The result feels less magical and more honest

My favorite part of this change is that it did not make the assistant feel more autonomous.

It made it feel more aligned.

The assistant now behaves closer to how a human collaborator would interpret the conversation:

if I said "just continue," it continues
if I said /yolo, it stops nagging me for every tiny step
if the next move is truly risky, it still pauses
if I want strict mode back, /safe restores it immediately

That balance is what I want from a local control plane: not maximum freedom, not maximum ceremony, just the right amount of friction in the right place.

CliGate is the open-source local control plane I use to route Claude Code, Codex CLI, channels, desktop control, and assistant workflows through one place: CliGate.

If you are building local agents, where do you draw the line between approval memory and real safety boundaries?

I Added WeChat to My Claude Code and Codex Workflow

CodeKing — Thu, 11 Jun 2026 07:47:14 +0000

The awkward part of local AI tooling is that "local" usually means "only useful while I am sitting at the keyboard."

That is fine when I am deep in an editor. It is less fine when Claude Code is waiting for approval, Codex finished a task, or I just want to ask "what happened?" from my phone.

I already had browser chat and a few external channels wired into CliGate. But for my daily workflow, one missing channel was obvious: WeChat.

The problem was not another bot

Adding a chat provider is easy if all you want is text in and text out.

That was not the workflow I wanted.

The useful version needs to preserve the shape of an AI coding task:

start a Codex or Claude Code run
keep follow-up messages attached to the same task
surface approvals when the runtime asks for permission
send progress and final results back to the user
remember whether the conversation is a new task, a status check, or a continuation

Without that, a WeChat integration would just become another notification pipe. Nice to demo, not very useful under pressure.

The painful case is familiar: a local agent starts doing real work, hits one approval prompt, and then silently waits in a terminal you are not looking at. The problem is not that the model cannot reason. The problem is that the control loop is trapped in the wrong place.

The fix was to treat channels as task surfaces

In CliGate, I ended up treating WeChat the same way I treat Telegram, Feishu, and DingTalk: not as separate products, but as surfaces over the same local task system.

The runtime is still local. Claude Code and Codex still run on my machine. The proxy, account routing, logs, approvals, and task records still live on localhost.

The channel only changes where I talk to the workflow.

That distinction matters. It means the WeChat provider does not need to know how to run Codex. It needs to know how to receive a message, map a user to a conversation, and hand that message to the same supervisor layer that the web chat uses.

The mental model looks like this:

WeChat message
-> channel gateway
-> supervisor conversation
-> Codex or Claude Code runtime
-> progress / approval / result
-> WeChat reply

The interesting part is the middle. A message like "status?" should not be forwarded to Codex as a random new prompt. It should be answered from the remembered task state. A message like "also update the docs" should usually continue the current task, not start from scratch with the default provider.

That task memory is what makes a channel feel like a real interface instead of a webhook.

What changed in the workflow

Before this, I had a split-brain setup.

The desktop dashboard was where the real task state lived. My phone was mostly for checking messages. If an AI coding task needed a decision, I had to return to the browser or terminal.

Now the chat app can stay in the loop:

start a coding task from WeChat
receive progress as the local runtime works
answer approval prompts without finding the terminal
ask for a status update without interrupting the agent
continue the same task with a short follow-up

That does not make WeChat special. That is actually the point.

The more useful design is that the channel is replaceable. Telegram, Feishu, DingTalk, WeChat, and the web dashboard should all speak to the same task model. Users can pick the surface that matches their day.

Why I kept the tools unchanged

I did not want to build a fake Claude Code or a fake Codex inside a chat app.

Those tools already have their own strengths. The better layer is a local control plane around them: one place for routing, credentials, approvals, task records, logs, and channel delivery.

That is what CliGate is trying to be.

You still run it locally:

npx cligate@latest start

Then the same machine that owns your code can also own the coordination loop. No hosted relay is required for the core workflow, and the AI coding tools do not need custom provider configs for every channel you add.

The lesson

The main thing I learned is that "mobile support" for local agents is not just a smaller UI.

It is a continuity problem.

If the phone cannot see the task state, approvals, runtime choice, and final result, then it is only a remote text box. If it can see those things, it becomes a practical control surface for work that still runs safely on your own machine.

That is the direction I want local AI tooling to go: the work stays local, but the conversation can meet you where you already are.

The project is open source here: https://github.com/codeking-ai/cligate

If you use AI coding agents, where do you want their progress and approval prompts to show up: terminal, browser, Slack, Telegram, WeChat, or somewhere else?

My Coding Agent Asked Permission for Every Tiny Step

CodeKing — Tue, 09 Jun 2026 07:09:30 +0000

The most annoying bug in my local AI assistant was not that it refused to ask for permission.

It was that it asked too often.

One task turned into a permission treadmill.

The approval loop felt safe but unusable

Approval prompts are good. I want a local assistant to stop before it runs commands, writes files, opens apps, or touches the desktop.

The problem is that real work is rarely one tool call.

If every step asks the same kind of question, the user stops evaluating risk and starts clicking through interruptions.

That is worse than unsafe. It trains the user to ignore the safety system.

The bug was treating approval as a single event

The old flow in CliGate looked roughly like this:

assistant chooses tool
-> policy says confirmation required
-> user approves
-> tool runs
-> assistant continues
-> next tool asks again

That was technically correct. Each tool call had its own confirmation.

But it missed the shape of the user's intent. The user was not approving "run one tiny probe." They were approving the assistant to continue one bounded task.

So I changed the behavior after the first approved action in a chat conversation.

The escape hatch matters too:

/safe

That turns the conversation back into explicit confirmation mode.

The continuation had to carry the real result

There was another subtle part.

When a user approves a pending action, the system cannot just say "confirmed" and stop. It has to continue the original job.

This made the assistant feel much less like a form with a chatbot attached to it. The flow became:

ask once for the risky boundary
execute the first step
continue the task with real observations
only interrupt again when the user explicitly returns to safe mode or a genuinely different boundary appears

The interesting part is that the fix is not "disable approvals." It is "remember what approval was for."

I also hit a language bug

This same continuation path exposed a smaller but very visible bug.

That produced an ugly mixed-language workflow: first approval in Chinese, later approval prompts in English.

The rule I am keeping

I do not think agent approval should be all-or-nothing.

For local tools, the useful middle ground is task-scoped trust:

ask before crossing a meaningful boundary
remember that approval for the current task
keep an obvious way to return to strict mode
do not let system continuation messages masquerade as user intent

That is now how I am shaping approvals in CliGate, the local control plane I use for Claude Code, Codex CLI, Gemini CLI, desktop automation, channels, and model routing.

The project is open source here: CliGate.

If you are building local agents, how are you handling approval fatigue: per tool call, per task, per session, or something more granular?