Atlas apply_patch fails with "Invalid patch format: missing Begin/End markers" because patch/index.ts locates the Begin and End markers by exact trimmed match and throws when either one is missing or out of order. The fix is to wrap the patch in the required Begin and End markers, in that order, with at least one hunk between them. Do not indent the marker lines, because the parser compares the trimmed line to the marker exactly. Two related failures come from the same tool: "apply_patch verification failed: no hunks found" when the markers are present but empty, and "patch rejected: empty patch" when there is no content at all.
Why does Atlas apply_patch reject the patch format
Atlas apply_patch rejects the patch format because patch/index.ts locates the Begin and End markers by exact trimmed match and throws when either is missing or out of order. There are 3 distinct rejections, and the parser will not infer a boundary it cannot see.
There are three distinct rejections, and reading which one you got is the fastest route to the fix. "Invalid patch format: missing Begin/End markers" means the structural envelope is broken: one marker is absent, or the End precedes the Begin. "apply_patch verification failed: no hunks found" means the envelope is intact but nothing is inside it, so the parser found a well-formed patch that changes nothing. "patch rejected: empty patch" means there was no content to parse in the first place. Each error names a different stage, and each is a hard stop rather than a warning. The strictness is deliberate: a patch tool that guesses at a missing boundary can write the wrong bytes into a source file, and that is a far worse outcome than a rejected call.
How to fix missing Begin/End markers in Atlas apply_patch
Fix the Atlas apply_patch marker error by wrapping the patch in the required Begin and End markers, in that order, with at least 1 hunk between them, and with no indentation on the marker lines. The parser compares the trimmed line to the marker exactly, so the marker text must match.
Order matters, presence matters, and position on the line matters. Begin comes first, End comes last, and everything the tool will act on lives between them. If your patch is being assembled programmatically or pasted through an intermediate layer, the marker lines are the first thing to inspect, because pretty-printers and message formatters routinely add indentation that a human eye skims right past. The other structural requirement is content: markers with nothing between them produce "apply_patch verification failed: no hunks found", which is a different error from a missing marker and points at a different mistake. Confirm both the envelope and its contents before re-running.
Why indentation breaks Atlas patch markers
Indentation breaks Atlas patch markers because patch/index.ts compares the trimmed line to the marker exactly. The documented rule is direct: do not indent the marker lines. In 2026, the most common source of an indented marker is a wrapper that reformats patch text on its way into the tool.
The most common way indentation sneaks in is through a wrapper. A patch nested inside a code block, quoted into a message, or emitted by a layer that indents its payload arrives at apply_patch with its marker lines pushed off the left margin. To a human reading the patch, nothing looks wrong. To patch/index.ts, which compares the trimmed line to the marker exactly, the marker line is no longer the marker. Keep patch text raw. Do not reformat it, do not re-wrap it, and do not let an intermediate layer prettify it on the way in. The parser is doing exact matching on purpose, and exact matching means the bytes you send are the bytes it judges.
Should I hand-repair a rejected patch in Atlas
No. If the patch was generated by a model, have it regenerate the patch rather than hand-repairing the markers. Atlas apply_patch rejected the patch because its structure is broken, and 1 broken envelope usually signals problems in the hunks too, which a marker edit does not repair.
Hand-repairing feels faster and often is not. A patch missing its Begin marker may also be missing hunks, may have hunks that were truncated mid-generation, or may have context lines that never matched the file. Patching the envelope makes the format error disappear and lets a semantically wrong patch through to the next stage, where it either fails on context or, worse, applies something you did not intend. Regeneration is the honest fix. Atlas computes a unified diff for every file edit and surfaces it for approval before writing, so a regenerated patch still gets a human review gate before anything lands on disk. Use that gate on a clean patch, not on one you spliced back together.
How to verify the Atlas patch format fix worked
Verify the Atlas apply_patch fix by re-running the tool. A valid patch clears all 3 rejections: "Invalid patch format: missing Begin/End markers", "apply_patch verification failed: no hunks found", and "patch rejected: empty patch". Atlas then surfaces the unified diff for approval before writing.
Clearing the format error moves the patch to the next stage rather than finishing the job, and that is worth understanding before you declare victory. A well-formed patch can still fail when the applier seeks its hunk context in the file and does not find it, which is a separate error with a separate cause. So verification here means specifically that the parser accepted the structure: markers found, in order, with hunks between them. Once the diff appears for approval, read it. Atlas snapshots file changes as git patches so edits can be diffed and rolled back, but reviewing the diff before it lands is still cheaper than rolling back after.
How to fix it
- 01Wrap the patch in the required Begin/End markers, in that order. A patch with an End before its Begin is out of order and is rejected.
- 02Ensure at least one hunk is present between the markers, otherwise apply_patch fails verification with: no hunks found.
- 03Do not indent the marker lines. The parser compares the trimmed line to the marker exactly, so leading whitespace on a marker is not tolerated.
- 04Check that the patch body is not empty. An empty patch is rejected separately with: patch rejected: empty patch.
- 05If the patch was generated by a model, have it regenerate rather than hand-repairing the markers.
Frequently asked questions
- what does Invalid patch format missing Begin/End markers mean in Atlas
- It means Atlas apply_patch could not find both markers. patch/index.ts locates the Begin and End markers by exact trimmed match and throws when either is missing or out of order.
- why does Atlas say apply_patch verification failed no hunks found
- The Begin and End markers were found but nothing usable sits between them. Ensure at least one hunk is present between the markers, otherwise the patch parses to zero hunks and is rejected.
- why does Atlas reject my patch as an empty patch
- Atlas apply_patch separately rejects an empty patch with: patch rejected: empty patch. There was no patch content to parse, which is a different failure from missing markers.
- can I indent the Begin and End markers in an Atlas patch
- No. The parser compares the trimmed line to the marker exactly, so an indented marker line does not match and the patch is rejected as invalid format.
- should I fix a broken patch by hand or regenerate it in Atlas
- Regenerate it. If the patch was generated by a model, have it regenerate rather than hand-repairing the markers, since a broken envelope often signals problems in the hunks too.
- does the Begin marker have to come before the End marker in Atlas
- Yes. patch/index.ts throws when the markers are out of order, so an End that precedes its Begin produces the invalid patch format error.
- how do I know my Atlas patch format is fixed
- Re-run apply_patch. A correctly formed patch parses without the invalid format, no hunks found, or empty patch errors, and Atlas surfaces the unified diff for approval before writing.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Atlas with IBM Granite Code 20B (Ollama): More Capacity, Less Window in 2026
IBM Granite Code 20B (Ollama) is 12GB on disk and Free (self-hosted), but the 20b tag drops to 8K tokens (8,192) where the 8B instruct advertises 125K.
Atlas with GPT-5.5 Pro: One Hard Question at a Time in 2026
GPT-5.5 Pro is OpenAI's April 2026 maximum-effort reasoning tier at $30 / $180 per Mtok on a 1,050,000 token window. Invoke it deliberately in Atlas, then switch back.
Atlas with Phi-4 (local via Ollama): The 16K Context Tradeoff in 2026
Phi-4 (local via Ollama) drives Atlas at Free (self-hosted) pricing with a 16K tokens (16,384) window. Setup, the 14B reasoning case, and where it breaks.
Atlas with Mixtral 8x7B (Ollama): Sparse MoE Throughput in 2026
Run Atlas on Mixtral 8x7B (Ollama): a 26GB Apache 2.0 sparse mixture of experts with 32K context, free self-hosted. Memory math, throughput, and honest limits.
Atlas with Llama 3.2 3B (local via Ollama): A 2.0GB Offline small_model for 2026
Llama 3.2 3B (local via Ollama) in Atlas for 2026: a 2.0GB pull, Free (self-hosted), 128,000 tokens of context, and the offline small_model that never touches a network.
Atlas for Express in 2026
Atlas is a terminal-native AI coding agent for Express in 2026. It reads your middleware order, wraps async route handlers, and runs mocha behind a prompt.
Atlas with Amazon Nova Micro in 2026: The Cheapest Model on Bedrock
Amazon Nova Micro costs $0.035 per Mtok input, the lowest price in the Bedrock catalog, with a 128K token context. Use it as Atlas's small_model, never as the build loop.
Atlas vs Gemini CLI: A Developer's Guide to Terminal AI Agents in 2026
Atlas vs Gemini CLI in 2026: Compare terminal AI coding agents. Atlas offers permission-gated tool calls and diff-based approvals. Gemini CLI provides a million-plus token context and a free tier.