MonkeyCode Under Parallel Tasks: Do the Patches Still Know Their Base Commit?

A developer tested MonkeyCode's parallel coding-agent tasks to determine whether patches identify their base commit, finding that parallel sessions create consistency problems. The experiment showed that silent base substitution is unsafe, while explicit conflicts or rerun requests are acceptable. The developer recommends rejecting runs where drift silently changes the base or cross-task files appear.

Two coding-agent tasks start from commit A . Task X edits authentication. Task Y edits logging. While both run, a human pushes commit B . If the patches do not identify their base, “apply both” is unsafe. Parallel agent sessions are a consistency problem, not only a speed feature. Here is a black-box experiment for MonkeyCode SaaS https://monkeycode-ai.net/ , not a claim about its concurrency implementation. A .Build a disposable repository: src/auth.py tests/test auth.py src/logging.py tests/test logging.py TASK X SENTINEL.txt TASK Y SENTINEL.txt Make both tests fail independently at A . Task X may edit only auth files; Task Y only logging files. Both are forbidden from changing either sentinel. Record requirement hashes and the full base SHA. Start both tasks as close together as the workflow permits. While active, push an unrelated documentation commit B . Capture: task id: "<id " requested base: "<A " reported or inferred base: "<SHA or unknown " changed files: test command: "<command " test result: "pass|fail|unknown" result revision: "<SHA or artifact " drift action: "none|reject|rebase|restart|unknown" unknown is honest observation, but may fail your adoption gate. Apply X and Y separately to clean checkouts of A . Check allowed files, focused test, unrelated fixture, and sentinels. Then evaluate both orders: A + X + Y A + Y + X Run both tests after each order. If only one order works, the tasks have a dependency that must be represented and reviewed. Now test B + X + Y . A clean application, explicit conflict, or request to rerun from B can all be reasonable. Silent base substitution is not. Finally, create two tasks that deliberately edit the same line. The required property is visible conflict and rerun evidence—not magical automatic merge. | Observation | Decision | |---|---| | Bases clear; isolated patches; both orders pass | Candidate | | Conflict explicit | Candidate with human merge gate | | Base unknown | Insufficient evidence | | Cross-task files appear | Reject run | | Drift silently changes base | Reject run | | Combined patch lacks rerun evidence | Block merge | MonkeyCode's README documents online managed environments plus task and requirement management, making it a practical candidate for this experiment. It does not promise the envelope or semantics above. Sources: MonkeyCode repository https://github.com/chaitin/MonkeyCode and SaaS https://monkeycode-ai.net/ . Limitations: two tasks are not a load test and cannot prove process- or tenant-level isolation. Disclosure: I'm a MonkeyCode user sharing my own experience, not affiliated with the project. This is one of several independently useful technical articles published by accounts managed by the same operator; it is not an independent endorsement. Which event should force a restart from a new base: human commit B , overlapping patches, or either one?