You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
feat(repo): --delegation and an execution id for repo run cells - #107
Under --tools all, Claude Code can start subagents, so a repo run cell was not a single-agent baseline. Nothing recorded how the agent was started either, so a rerun with other tool arguments reused old cells.
run_cell
+ execution = {id: profile.execution_id(tools, delegation), tools, delegation}
if result.json exists and not --force
+ if its execution.id != execution.id (legacy result = native)+ raise ExecutionMismatch # reported as crashed; --force or new --batch
skip
argv = profile.argv(..., delegation=opts.delegation)
+ meta.json / result.json += execution
repo run --delegation native|none. The default native keeps today's argv. A profile without delegation.none is refused before anything runs.
The id is a sha256 prefix over the profile name, invoke, the resolved tool arguments, env_set, config_files and prompt_suffix.
Schema: optional delegation property in harness_profile.v1 (additive; schema-compat passes).
Evidence
Before: run batch b1 with --tools all, then again with other tool args → 0 ran, 1 already done: the old cell counted as the new configuration. After:test_a_cell_is_reused_only_by_the_same_execution: native run, then --delegation none → 1 crashed: the cell finished with another execution (89c98badf275, delegation native) than this run (4f14be0df49a, delegation none). With --force it reruns, and the argv ends with the profile's no-subagent args.
make ci-local: 18 pass. Bandit fails locally only because it scans a local .venv; with that excluded, bandit -r . -ll -x ./.venv is clean.
Merge Danger
Door: two-way
Blast Radius: resumed batches
After upgrading, any change to the built-in profile changes the id, so resuming an old batch reports its finished cells as crashed instead of reusing them. Old results without execution still count as native, so an unchanged resume works. --force or a new --batch is the way out.
✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.34%. Comparing base (36e2244) to head (510b1ee).
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.
The reason will be displayed to describe this comment to others. Learn more.
🔵 Needs a closer look
Execution fingerprints omit profile-controlled environment and guidance settings, allowing stale results to be reused.
No open issues 🎉
1 previously missed issue
In code that hasn't changed since last review
Include environment and bridge inputs in fingerprint
dokimi/dokimi/repos/harness_profile.py:119
The fingerprint omits env_allow, config_dir_env, and bridge, although they affect the agent's inputs. Changing the environment allow-list or config-directory variable changes the environment passed by run_cell; changing bridge.content changes the guidance written for guidance:bridge. These edits leave the ID unchanged, so resuming the same cell silently reuses the old result. Include these fields in the hash and add regression tests that verify such profile edits prevent reuse.
The reason will be displayed to describe this comment to others. Learn more.
The mechanism is sound: the flag, the refusal before anything runs, and the execution record all do what the description says, and make ci-local is green. Three things are worth fixing before merge: the docs for what the id covers (inline), the tests that pin it (inline), and the mixed batch in item 1 below.
Mutation run on the new code, 6 mutants: 4 pass the full suite (the run-level harness bin/version in the id, the legacy-result clause, env_set/config_files/prompt_suffix in the key, the pre-run refusal). 2 are killed (delegation= dropped from argv() and from AgentOptions).
A repro of a batch rerun with another --delegation, with the container runner faked.
Findings that sit outside the diff or span several files:
A rerun that adds cells to a finished batch under another --delegation mixes executions in one batch. Run --reps 1, then rerun with --reps 2 --delegation none: r1 is reported crashed (finished with another execution (53028ce4e5e7, delegation native) than this run (837f503d490c, delegation none)), r2 runs under none. The batch then holds a native cell and a subagent-free cell in the same arm, summarize shows missing == [], and compare.py / report.py never read execution. The exit code is non-zero, but anyone reading only the report gets a silently mixed comparison. Suggestion: refuse the whole invocation up front when any finished cell has another execution id, or have compare stamp the execution ids per batch the way it stamps harness_versions.
Non-blocking: with --tools none or --tools read, --delegation none has the same id as native.tool_args falls back to the mode's own arguments, so a --tools none cell recorded as delegation: native is reused by a --delegation none run (0 ran, 1 already done) and keeps delegation: native. The command line is identical, so reuse is right, but the contract says another --delegation does not reuse the cell. Say so in the docs, or record the delegation actually in effect.
I agree with @copilot-pull-request-reviewer that env_allow, config_dir_env and bridge are missing from the id; the test gap below would hide it.
Checked, no issues
Schema: the delegation property in harness_profile.v1.json is optional and additive; schema-compat passes.
Refusal: a profile without delegation.none is refused with declares no `delegation: none` , and no agent container starts.
Argv path:--delegation none reaches the container argv end to end (killed by two mutants).
Readers:compare.py, report.py and manifest.py ignore the extra execution key.
Changelog fragment: present, in the right directory, with Added and Changed sections.
The reason will be displayed to describe this comment to others. Learn more.
Warning
Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.
…N_MODES, include env-shaping profile fields, use resolved binary path, improve test
- Use DELEGATION_MODES constant in repo_run.py choices instead of duplicating tuple
- Add env_allow and config_dir_env to execution_id key to detect profile env changes
- Use resolved absolute path str(harness_bin.resolve()) instead of just harness_bin.name to catch binary path changes
- Fix brittle test assertion: check "--no-agents" exists in argv, not that it's the last element
- Add test_a_changed_harness_binary_crashes_on_resume to verify binary path changes invalidate reuse
Addresses Copilot review comments on PR intel#107.
Signed-off-by: Nikolay Petrov <nikolay.a.petrov@intel.com>
Include bridge configuration in guidance fingerprint
dokimi/dokimi/repos/harness_profile.py:120
For guidance:bridge cells, prepare_workspace() uses bridge.for, bridge.write, and bridge.content to generate guidance files, but this fingerprint omits them. Changing only the bridge configuration therefore leaves the ID unchanged, and resuming silently reuses results produced with different guidance. Include bridge in the fingerprint and add a regression test that changes only the bridge configuration.
Fix fingerprint tests to isolate the setting under test
dokimi/tests/test_repo_reach.py:240
The env_set, config_files, and prompt_suffix tests each create profiles in different directories. _profile() embeds those directories in invoke via the fake_harness.py path, so each assertion would still pass if its tested field were removed from the fingerprint. In all three tests, use the same directory for both variants and load the first profile before overwriting the file, so only the setting under test changes.
The reason will be displayed to describe this comment to others. Learn more.
Review at 522dd08. env_allow and config_dir_env are in the id now, and --delegation takes its choices from DELEGATION_MODES. Both of my threads are only partly fixed, and the switch to the resolved binary path makes the id depend on where the binary lives.
Mutation run on execution_id and execution_record, with the suite at 159 passed on the unmutated code: dropping profile, env_set, config_files, prompt_suffix, env_allow or config_dir_env from the key, one at a time, still gives 159 passed. So does .name in place of str(...resolve()) in execution_record. Dropping harness_bin or harness_version fails the suite.
Reproductions for the code findings, with the container runner faked.
I agree with @copilot-pull-request-reviewer that bridge is missing from the id and that the three execution_id_pinned_by_* tests need a shared directory. New evidence: with claude-code.yaml loaded, changing only bridge.content, bridge.write or bridge.for leaves the id unchanged (88faacbe8544), so a guidance:bridge cell is reused after the bridge text changes. egress and guidance.names are not hashed either.
Still open from my earlier review:
dokimi/docs/repo-evaluation-contract.md:689: the list now says "harness binary name (--bin file name)", but runner.py:96 hashes the resolved absolute path. The profile name, env_allow and config_dir_env are in the key and not in the list. The changelog fragment and the execution_id docstring (harness_profile.py:111-115) carry the same "binary name" wording.
dokimi/tests/test_repo_reach.py:224: the new tests do not pin what they claim. test_execution_id_pinned_by_env_set, _config_files and _prompt_suffix build their two profiles in different directories, and _profile() writes the directory into invoke, so the ids differ whatever the field holds. With the key field dropped, each still passes. Same directory, different env_set: ids differ. Different directories, same env_set: ids also differ. test_execution_id_pinned_by_profile_name loads claude-code twice and never varies the name. Still missing from my list: a hand-written legacy result.json reused by native and refused by --delegation none (replacing the or (not ran and ...) clause at runner.py:166 with or False, or with not ran, passes the suite), and the refusal test asserting that no version probe ran.
Run: full suite, ruff, mypy and bandit on the head and on the merge with main, plus Claude Code 2.1.304's system/init tool list for each --delegation.
--delegation none --tools all -> the init tools still include Workflow, which starts subagents on its own -> no subagent-starting tool. Fixed in a3b74ca (Workflow denied; test plus contract and changelog updated). A deny-list will go stale with new releases. An allow-list, or refusing a none run whose init tools list Agent/Task/Workflow, would hold.
A pre-PR result.json (no execution), rerun with --tools read or with a changed harness binary -> 0 ran, 1 already done -> not reused, as the changelog and contract §7 say. Alternatively, the docs should say that a pre-PR cell needs --force or a new --batch.
Still open: the review threads on the id inputs listed in the docs, on the untested key fields, on mixed executions in one batch, on --tools none/read under none, and on bridge/egress/guidance being left out of the id.
The reason will be displayed to describe this comment to others. Learn more.
Review at 2a9b1ad. The id now hashes the executable's bytes, so an unchanged harness resumes from any path, and bridge, egress and the Workflow deny are in. The per-field pins share one directory now and the legacy-result clause is killed. Two points are left, one in the body and one inline, plus the open thread.
Mutation run on execution_id, execution_record, run_cell and repo_run.py, on a baseline of 162 passed in test_repo_run.py, test_repo_reach.py and test_repo_runner.py. Dropping harness_sha256, env_set, config_files, prompt_suffix, bridge or egress from the key fails the suite. Replacing the legacy clause at runner.py:175-176 with or False or with not ran fails it too.
A repro of a rerun with more reps and another --delegation, with the container runner faked.
Finding that spans several files:
A rerun that adds cells to a finished batch under another --delegation still mixes executions in one batch. Run --reps 1, then --reps 2 --delegation none: r1 is reported crashed (finished with another execution (b47842628694, delegation native) than this run (cb0f56995e76, delegation none)), r2 runs under none. summarize then gives missing == [] and two passing cells, one native and one subagent-free, in the same arm. report.py and compare.py never read execution, so the report pools them. The exit code is non-zero, but a reader of the report alone sees no sign of it. This is the comparison the PR sets out to keep apart. Suggestion: refuse the whole invocation up front when any finished cell has another execution id, or have compare stamp the execution ids per batch the way it stamps harness_versions.
Still open from my earlier review:
dokimi/tests/test_repo_run.py:166: the refusal test only asserts that no spec with -p in its argv ran, so a harness_version probe is not counted. Deleting the pre-run profile.tool_args(args.tools, args.delegation) at repo_run.py:184 still gives 162 passed; with the assertion changed to setup["runner"].specs == [] that mutant fails on argv=['/eval/harness/fake-agent', '--version'].
dokimi/tests/test_repo_reach.py:228: test_execution_id_pinned_by_profile_name loads claude-code twice and never varies the name. Dropping profile and invoke from the key at harness_profile.py:117 together still gives 162 passed. No test varies env_allow or config_dir_env either. Add one _ids_differ_only_by assertion for each of profile, invoke, env_allow and config_dir_env.
Checked, no issues
Path-independent id:test_the_same_harness_bytes_resume_from_any_path and test_a_changed_harness_binary_crashes_on_resume hold; the digest read costs about 0.07 s for a 200 MB file per cell.
Schema: the delegation property stays optional and additive; schema-compat passes.
Refusal: a profile without delegation.none is refused before any cell runs.
Profile and docs agree on the deny list:claude-code.yaml and the contract example both list Agent, Task and Workflow.
The reason will be displayed to describe this comment to others. Learn more.
Review at ffdbda0. The change since 2a9b1ad is docs only, and it closes the docs thread: the contract, the changelog fragment and the execution_id docstring now list every field the key hashes. The test gaps in the other thread are untouched, so it stays open.
Mutation run on the baseline of 162 passed in test_repo_run.py, test_repo_reach.py and test_repo_runner.py: dropping profile and invoke, env_allow and config_dir_env from the key (checked one at a time, and all four together) still gives 162 passed. Deleting the pre-run profile.tool_args(...) at repo_run.py:184 also gives 162 passed.
Still open from my earlier review:
dokimi/tests/test_repo_reach.py:225: test_execution_id_pinned_by_profile_name loads claude-code twice and never varies the name; no test varies invoke, env_allow or config_dir_env. Add one _ids_differ_only_by assertion for each.
dokimi/tests/test_repo_run.py:166: the refusal test only counts specs with -p, so the version and isolation probes go unseen. Assert setup["runner"].specs == []; with that, the mutant that deletes repo_run.py:184 fails on the --version probe spec.
The mixed-batch point from my review at 2a9b1ad still applies: runner.py, report.py and compare.py are unchanged since then. I agree with @xaleryb that the contract should say a pre-PR cell is matched on delegation only.
Checked, no issues
Docs vs key: the field list in the contract, the changelog fragment and the docstring matches execution_id field for field.
CI: schema-compat, mkdocs build, mypy, bandit and the changelog fragment check pass.
The reason will be displayed to describe this comment to others. Learn more.
When delegation.none does not list the tool mode, this falls back to the native arguments, but the cell is still recorded as delegation: none. A custom profile with delegation: {none: {}} passes the pre-run check, and --tools all --delegation none then runs with Agent/Task/Workflow allowed. Please refuse a tool mode that delegation.none does not list, and list none and read explicitly in claude-code.yaml (for them the arguments are the same as native).
The reason will be displayed to describe this comment to others. Learn more.
Done in cc77c0e (option a). tool_args now treats delegation.none as an allow-list: a tool mode it does not list raises ProfileError instead of falling back to the native args. claude-code.yaml lists none and read explicitly. The cell's execution.delegation records the delegation whose args ran (native for none/read, where the args are identical), so the record matches the argv.
The reason will be displayed to describe this comment to others. Learn more.
A result.json from before execution ids passes this check for any --tools, harness binary or profile edit, because ran.get("id", execution["id"]) always matches. It is refused only under --delegation none, even with --tools read where the command line is the same. Please treat an unrecorded id as a mismatch, or say in the contract and the changelog that a pre-PR cell is matched on delegation only.
The reason will be displayed to describe this comment to others. Learn more.
Done in cc77c0e (option a). A result.json with no execution is no longer reused (ExecutionMismatch, unrecorded) unless --force or a new batch. Also, run_batch now refuses up front a batch dir that holds cells of another execution id. Tests added.
The reason will be displayed to describe this comment to others. Learn more.
This check only needs the profile, but it runs after _context(pin=True), so a refused --delegation none has already pinned the batch and may have built the image. Please move it right after load_profile(args.harness).
The reason will be displayed to describe this comment to others. Learn more.
Fixed in be33310: the --delegation check now runs right after load_profile, before the batch lock and _context(pin=True), so a refused run pins nothing and builds no image. Regression test test_a_refused_delegation_none_leaves_no_batch_behind fails on the previous commit.
Claude Code 2.1.304 offers a Workflow tool that starts subagents on its
own path, so denying only Agent and Task left a delegation: none cell
able to delegate. The init event's tool list now drops Workflow too.
Signed-off-by: Alexander Rybkin <alexander.rybkin@intel.com>
The id left out bridge.for/write/content (the guidance written into the
workspace) and egress (the container's network), so a changed bridge or
egress reused the finished cells. The three env/config/suffix pin tests
now load two profiles from one directory and vary only the field under
test, so each fails if its field drops out of the key.
Signed-off-by: Nikolay Petrov <nikolay.a.petrov@intel.com>
The contract, changelog fragment and execution_id docstring named only
invoke, tool arguments, env_set, config_files, prompt_suffix, the
executable digest and version. The key also hashes the profile name,
env_allow, config_dir_env, egress and bridge, so editing one of those
reports finished cells as crashed without the docs saying so.
Signed-off-by: Nikolay Petrov <nikolay.a.petrov@intel.com>
The delegation check ran after the batch was locked and pinned, so a refused
run could leave a batch behind. Move it up to the profile load.
Pin the execution id by profile name and invoke, and cover a refused
--delegation none leaving no batch directory.
Signed-off-by: Nikolay Petrov <nikolay.a.petrov@intel.com>
…that cannot run their task
--force keeps the finished cells of a task the host cannot run, and the
up-front check skipped them as cells of the plan, so a forced rerun with
another --tools or --delegation left both executions in one batch.
Signed-off-by: Alexander Rybkin <alexander.rybkin@intel.com>
…from run_batch; test(repo): pin the recorded tools mode and the check's tolerance of unreadable results
Signed-off-by: Nikolay Petrov <nikolay.a.petrov@intel.com>
…profile schema
This text was added in the resolutions of merge commits ecea37d and d45da46, which a linear rebase drops.
Signed-off-by: Nikolay Petrov <nikolay.a.petrov@intel.com>
Re-checked at 888dfa2, on the head and on its merge with main eaad684. Ran the full suite, ruff, mypy and bandit, re-ran the original input of every earlier point (legacy result with --tools read or a changed binary, --force mixing reps, the allow-list with --tools read, a rerun refused rather than crashed, the kept cells of an unsupported task, plan.json after a refusal), and ran mutants on the second --force check, the plan order and the Workflow deny. All of them pass and each mutant is caught. Nothing is open. The red Tests jobs come from test_growth_ratchet on the old base (compare.py::_provenance_warnings), and the merge with current main passes, so re-run CI before merging.
make ci-local: 27 passed, 2 failed, 7 skipped; 7,273 tests. test_no_file_or_function_grew_past_its_baseline fails on compare.py::_provenance_warnings (complexity 11, no baseline entry), a file this PR does not touch. pip-audit reports gitpython 3.2.0 (CVE-2026-114145). Neither comes from this PR.
Mutation run, 61 mutants on runner.py, repo_run.py and the new helpers (_probe_failed, _clear_unsupported_markers, the second --force check, check_batch_executions, the execution record): all killed except the two below and equivalent ones. The harness_profile.py and claude-code.yaml mutants I ran (tool_args, effective_delegation) are killed as well.
Offline repros of multi-model resume, --jobs 2, and custom profiles with delegation blocks, with the container runner faked.
Checked, no issues
Plan on a refused --force:_record_plan runs after the second check, so a refused run leaves plan.json alone.
Second-check mutants: dropping the check, inverting unsupported, or checking all cells each fail the suite.
Allow-list:tool_args raises for a mode delegation.none does not list; the contract's example profile parses and matches claude-code.yaml.
Schema:delegation is optional and additive; schema-compat passes.
The reason will be displayed to describe this comment to others. Learn more.
I pushed a commit per nit, up to 651938c, which fix the two nits from my review:
d12aeaa: dokimi/tests/test_repo_run.py:181: added a test that strips execution from a finished result, skips the batch check, and asserts the rerun is refused as unrecorded without starting an agent.
651938c: dokimi/docs/repo-evaluation-contract.md:1003: dropped "or similar profile field" and ended the list with the hashed fields; the changelog fragment now says "an edited profile field listed above".
make ci-local at 651938c: 27 passed, 2 failed, 7 skipped (same two failures as at the reviewed head).
Not approving yet. Still open: the risk from my review.
@antonwolfy thanks for d12aeaa and 651938c. Both stay as pushed. This reply answers the open items in your 10-23 review. No new commits from me in this round; comment only.
Decisions
Nit d12aeaa, run_cell reuse of a result without execution: accepted, no code change. test_a_cell_finished_without_an_execution_is_not_reused_even_if_the_batch_check_is_skipped (dokimi/tests/test_repo_run.py:194) pins it.
Nit 651938c, "or similar profile field": accepted, no code change. The contract list now ends on the hashed fields, and the changelog says "an edited profile field listed above".
"The risk from my review": I read this as the mixed-batch finding (your 2a9b1adMake dokimi public #1): report.py and compare.py pool two executions in one row. Tell me if you meant something else. Decision: keep the refusal, do not stamp execution into report/compare. With the refusal in place, one batch dir cannot hold two execution ids:
Non-forced run: check_batch_executions (dokimi/dokimi/repos/runner.py:126) refuses before any agent starts if any finished cell has another id or no execution. Test: test_a_batch_dir_with_cells_of_another_execution_is_refused_up_front (test_repo_run.py:233).
--force: replaces only the cells of the run's plan. A finished cell outside the plan with another id refuses the run. Test: test_force_does_not_pool_executions_across_the_plan (test_repo_run.py:148, from 14cc74bb). Kept cells of a task the host cannot run get the same check: test_force_checks_the_kept_cells_of_the_unsupported_task_and_not_the_replaced_ones (test_repo_host.py:336, from c68a1a669). A refused run leaves plan.json alone (7c7327dde).
Per cell: run_cell raises ExecutionMismatch on any id mismatch (runner.py:212). Tested with the batch check skipped: test_repo_run.py:178.
Concurrent runs: batch_lock (runner.py:426) refuses a second repo run on a live batch dir. This predates the PR.
Pushes since your 10-22 review
The branch was rebased after these were pushed, so some SHAs changed. Old SHAs are in your reviews; the content matches unless noted.
napetrov: a6e43a3b → 7c7327dde (refused --force leaves plan.json alone; kept-cell and per-cell reuse tests); 130a2fc3 → tests test_the_cell_records_the_tools_mode_it_ran_with (test_repo_run.py:243) and test_an_unreadable_or_unparsable_result_does_not_stop_the_batch_check (:250), plus refactors d2bbc168e / f62b1f653 (helper extraction from run_batch); 1eba297a → ce28c4cc9 (growth baseline entry removed; context changed); 888dfa21 → 888dfa212 (delegation.none allow-list docs); b013eddb0 (test that a harness reporting another version with the same bytes is another execution); merges 8a5824ff and 78a8a0dd8 of intel/main, no PR-diff change beyond main.
The reason will be displayed to describe this comment to others. Learn more.
LGTM. The harness-version pin I asked for is in, and it kills the mutant. The up-front batch refusal, the --force checks and the delegation.none allow-list hold up.
Mutation run on execution_record, execution_id, check_batch_executions, the --force skip sets, effective_delegation, tool_args and the execution record: 16 mutants, all killed. Replacing opts.harness_version with None in execution_record fails test_a_harness_reporting_another_version_with_the_same_bytes_is_another_execution (the second run prints 1 already done instead of refusing).
Offline reproductions with the container runner faked: a rerun with another --delegation or --tools, --force, a multi-model batch with --jobs 2, a pre-execution and a malformed result.json, and odd delegation shapes in a profile. Each ends in a clean refusal or a correct reuse.
The new tests run against the base modules: 25 fail there and all pass at the head.
Checked, no issues
Schema:delegation stays optional and additive; schema-compat passes.
Docs vs key: the field list in the contract and the changelog fragment matches execution_id field for field; mkdocs build --strict passes.
Mixed batches: a non-forced rerun and a forced rerun both refuse before any agent starts when a finished cell has another id, so one batch directory cannot hold two executions.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
antonwolfy
left a comment
github-actions
Bot
added
the
cli-interface-change
Summary
Under
--tools all, Claude Code can start subagents, so arepo runcell was not a single-agent baseline. Nothing recorded how the agent was started either, so a rerun with other tool arguments reused old cells.repo run --delegation native|none. The defaultnativekeeps today's argv. A profile withoutdelegation.noneis refused before anything runs.idis a sha256 prefix over the profile name,invoke, the resolved tool arguments,env_set,config_filesandprompt_suffix.delegationproperty inharness_profile.v1(additive; schema-compat passes).Evidence
b1with--tools all, then again with other tool args →0 ran, 1 already done: the old cell counted as the new configuration.After:
test_a_cell_is_reused_only_by_the_same_execution: native run, then--delegation none→1 crashed: the cell finished with another execution (89c98badf275, delegation native) than this run (4f14be0df49a, delegation none). With--forceit reruns, and the argv ends with the profile's no-subagent args.test_delegation_none_drops_the_subagent_tools_and_changes_the_execution_id,test_delegation_none_is_refused_before_anything_runs_when_the_profile_cannot.make ci-local: 18 pass. Bandit fails locally only because it scans a local.venv; with that excluded,bandit -r . -ll -x ./.venvis clean.Merge Danger
Door: two-way
Blast Radius: resumed batches
After upgrading, any change to the built-in profile changes the
id, so resuming an old batch reports its finished cells as crashed instead of reusing them. Old results withoutexecutionstill count as native, so an unchanged resume works.--forceor a new--batchis the way out.🤖 Generated with Claude Code