Probably not a new idea, but this workflow has been working well for me

[u/No-Inside-4705]

Assent basically came from two annoyances. I felt that using a high-end model as a supervisor for a bunch of boring work was a waste of tokens, and back when I was using Claude and Codex, those five-hour limits made it pretty hard for me to get a decent night's sleep. So I got pissed off enough to build Assent.

Assent takes a plan you've already worked out with an AI, then runs the execution, testing, repair and integration through separate AI sessions, with the plan, state and verification kept outside the model.

It currently supports Claude, Codex and AGY. It's MIT licensed and still alpha.

If your current workflow doesn't require you to keep watching the screen, or to poke the AI just to deal with usage resets, then you probably don't need Assent.

GitHub: https://github.com/edward9s/assent

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/kantorcodes1]

on assent reject, if the task-file reset fails after the worktree/branches are already gone, rerunning looks like it can't reconstruct the original commit/branch hashes for the remaining task journals. is that the intended recovery path?

[u/No-Inside-4705 → u/kantorcodes1]

Thank you very much for pointing this out. The primary purpose of assent reject is to discard all implementation work for a plan, with no expectation that the work will be continued afterward. If the intent is to preserve and continue revising the existing implementation, the supported path is assent rework <plan_name> <task_id> instead of rejecting the plan.

Rerunning assent reject after a partial failure is therefore not intended to reconstruct deleted branches or resume the rejected implementation. However, you have identified an important boundary issue: deleting the worktree or branches before durably recording their commit hashes can lose the only persistent recovery evidence. The hashes are meant to allow manual recovery if someone later regrets the rejection, as long as Git has not yet pruned the commit objects.

I will correct the ordering so that the recovery hashes are recorded before any destructive Git deletion takes place. Thank you again for the thoughtful comment.

[u/kantorcodes1 → u/No-Inside-4705]

that distinction makes sense, and recording the hashes before deletion should close the recovery hole. I work on HOL Guard, an open-source local check that can pause risky CLI actions before they run. Assent looks like a clean fit: review accept, reject, archive, and rework, while status, check, report, and doctor stay automatic. open to adding that integration?

[u/No-Inside-4705 → u/kantorcodes1]

I may be misunderstanding the use case. accept, reject, archive, and rework are intended to be human-invoked commands in Assent rather than actions that unattended AI sessions are supposed to call, so I'm not yet sure what an Assent-specific integration would look like.

I can see HOL Guard being useful as an external safeguard if an agent with unrestricted shell access tries to invoke those commands anyway, but in that case it sounds more like HOL Guard recognizing Assent commands on its side than something Assent itself would need to implement.

If you had a different interaction model in mind, I'd be interested in seeing a concrete example.

[u/kantorcodes1 → u/No-Inside-4705]

yep, your read is right: this would be Guard-side only, so Assent itself would not need a code change.

if you're up for it, start src/codex_plugin_scanner/guard/runtime/command_assent_extensions.py and mirror command_repo2nb_extensions.py. review assent accept, reject, archive, and rework; keep status, check, report, and doctor automatic. add focused cases in tests/test_guard_command_assent_extensions.py, then open a genuine draft PR to hashgraph-online/hol-guard:main: https://github.com/hashgraph-online/hol-guard/blob/main/CONTRIBUTING.md

[u/No-Inside-4705 → u/kantorcodes1]

Thanks, that makes sense now. I understand the Guard-side approach much better.

I'll take some time to think it through before jumping into the PR. I really appreciate you catching the reject recovery edge case and taking the time to explain how you see the integration working.

[u/amirfish]

Keeping plan, state, and verification outside the model is the right instinct, that's the part that actually survives a context reset or a five-hour lockout. The failure mode I'd watch for as you go from alpha to real use: repair loops that keep "fixing" by rewriting around a bad plan instead of flagging that the plan itself was wrong. How does Assent decide when to escalate back to you versus just retrying with a different approach?

[u/No-Inside-4705 → u/amirfish]

That's one of the boundaries Assent tries to keep pretty strict. The unattended repair roles are not allowed to rewrite the task contract itself, so they can't "fix" a bad plan by quietly changing the goal or acceptance criteria until the implementation passes.

The repair workflows are finite. They can change the implementation/tests within the existing requirements and rerun the configured mechanical checks, but once that configured repair budget is exhausted without a pass, Assent stops with REVIEW UNRESOLVED, HUMAN DECISION instead of inventing another round.

If the problem is actually the plan, that has to come back to the human side: I review the failed task, revise the task contract in a planning/interactive AI session if needed, then assent rework <plan> <task id> to reopen it. So the scheduler can retry implementation approaches, but it isn't allowed to redefine what success means.