fix: the CLI's agent default could not write (#165)

[thedancingdeveloper]

session_executor.DEFAULT_AGENT_COMMAND carries --permission-mode acceptEdits. The CLI's --agent default was a second, separately written
string that did not. So run --session-host without the flag produced an agent
that was refused every Edit.

What it looks like from outside

The agent finishes cleanly, the harness reports no_changes, and the item
fails as "the agent made no changes" — indistinguishable from a model that
considered the task and declined. The agent's own account sat in a session
scrollback nothing reads:

every write to the working tree is being denied by the permission layer …
The files themselves are writable, so this is the harness permission mode,
not the filesystem. I'm not going to route around a declined permission via
shell redirection.

It then wrote out the complete change it would have made. Correct behaviour
throughout, recorded as producing nothing — and it cost a full agent run,
which in session mode is minutes of a real CLI agent rather than one API call.

The fix

The CLI takes the executor's command instead of declaring its own.

The test asserts that relationship rather than the string, because the defect
was a second default existing at all: a literal that happens to match today
drifts again tomorrow, which is precisely what happened to the review rubric
(#167).

Scope

This is half of #165. The other half — that a permission refusal still reports
as no_changes — is untouched, and it is the half that matters when the cause
is a deployment rather than a flag someone dropped.

All four gates green.

🤖 Generated with Claude Code