Processing one satellite image in ESA SNAP is manageable. Repeating the same steps across a month of acquisitions is where the work grows: open each product, select the study area, align the required bands, apply quality masks, calculate an index, and save the results. Small differences in those settings can make later comparisons harder to trust.

Claude and Codex can help turn that sequence into a reusable processing workflow. SNAP’s Graph Processing Tool (gpt) executes XML graphs containing the processing steps and parameters. The assistant helps prepare the graph, organize batch runs, and investigate errors; SNAP performs the image processing.

With Vagon Cloud Computer, SNAP, your chosen assistant, source imagery, and processing tools share one Windows workspace. You can build the workflow, run it, and inspect the resulting rasters without moving between separate environments or tying up your own computer’s processing resources.

This guide uses Sentinel-2 Level-2A imagery to produce masked NDVI outputs for a defined study area, starting with one verified product before expanding to multiple dates.

Source: ESA SNAP Documentation

Start with a Defined Satellite Processing Task

Before building a graph, decide what the workflow should produce. “Process these satellite images” leaves too many choices open, including the product level, spectral bands, output resolution, and treatment of cloudy pixels.

For this walkthrough, the task is to generate a masked Normalized Difference Vegetation Index, or NDVI, raster for a defined area from each selected Sentinel-2 Level-2A product.

Sentinel-2 Level-2A products already provide atmospherically corrected surface reflectance and supporting quality layers. We will not add atmospheric correction simply because it appears in another satellite-processing tutorial.

The 20 m grid is a deliberate choice for this example, not a universal requirement. It accommodates the quality layer while keeping the output manageable. Resampling the reflectance bands to that grid changes their spatial sampling; it does not create additional detail.

Keep the valid-pixel mask alongside the NDVI raster. It records which pixels passed the selected screening rules, helping distinguish excluded observations from genuine index values.

Finally, keep the scope clear: this is an optical vegetation-index workflow. Sentinel-1 radar products require different operators and processing decisions. Claude or Codex should flag an incompatible input rather than attempt to force it through the same graph.

Bring SNAP, Your Agent, and the Data into One Workspace

Keep the application, processing graph, and satellite products on the same cloud desktop. Claude or Codex can then prepare commands against the files SNAP will actually read, while you inspect the results in SNAP Desktop.

1. Select the applications

During Vagon computer creation, use application selection to choose ESA SNAP and your preferred AI tools. Include Python if you want to use the batch runner described later.

Once the desktop is ready, open SNAP and check that the installed toolboxes support Sentinel-2 products. Sign in to your chosen assistant separately. You only need one assistant to follow this guide.

2. Confirm command-line access

Open a terminal inside the Windows desktop and run:

The help output should list the available processing operators. If Windows cannot find the command, locate gpt.exe in the SNAP installation’s bin folder and invoke it by its full path.

Check the operators required for this workflow:

These checks use SNAP’s command-line interface; they do not process imagery or require an MCP connection. Save the SNAP version and relevant operator help with the project so the assistant can work from your installed environment.

3. Transfer complete products

Use Vagon Files to bring in existing imagery and your area-of-interest file. Alternatively, download products directly inside the cloud desktop through your chosen data provider.

Preserve each Sentinel-2 SAFE product’s internal structure. Copying only a few JPEG2000 bands can leave out metadata or quality information needed by the workflow.

Organize the working directory:

Keep source products unchanged in input. Allow storage for extracted products, temporary files, and outputs, not just the original downloads. Open one product in SNAP before proceeding to confirm that its bands and metadata are readable.

Give Claude or Codex a Processing Brief, Not an Open-Ended Instruction

The assistant’s first task should be inspection, not processing. Give it the project location and ask it to establish whether the available products match the workflow.

Some information may require opening the product through SNAP rather than reading filenames. A plausible product name does not prove that the download is complete or that every required band is readable.

Source: ESA SNAP Documentation

Keep responsibilities explicit:

After inspection, ask for a proposed processing plan. It should name the selected bands, target grid, resampling methods, excluded quality classes, and output format. Approve those choices before allowing execution.

Neither a chat session nor a preinstalled assistant automatically has permission to run commands or control SNAP. Use the terminal access available in your configured agent environment, or execute the reviewed commands yourself. If computer use is configured, it can support visual checks in SNAP Desktop, but it does not replace numerical validation of the raster.

Build a Reviewable Graph Before Writing a Batch Script

Use SNAP’s Graph Builder to make the processing sequence visible before automating it. Open Tools → Graph Builder and assemble this chain:

Read → Resample → Subset → BandMaths → Write

Each node should have one clear responsibility. Claude or Codex can help prepare and inspect the XML, but review the graph against the installed operators rather than accepting a generated file without checking it.

Source: Freie Universität Berlin

Read and align the required bands

Point the Read node to the complete Sentinel-2 L2A product using its supported product entry point, not an isolated band image. Confirm that SNAP exposes B4, B8, and the Scene Classification Layer.

The Resample operator brings a multi-resolution product onto a single grid. For this example, select the native 20 m SCL band as the reference and aggregate the 10 m reflectance bands to match it.

Mean aggregation is a reasonable starting choice for the continuous reflectance bands in this example. Do not average SCL class numbers: they identify categories, not continuous measurements. Verify that the reference classification remains unchanged.

Restrict the processing area

Configure Subset with the approved area of interest and retain the bands needed for the calculation and quality screening.

Check the AOI’s coordinate reference before translating it into the geometry expected by SNAP. A rectangle expressed in projected meters cannot simply be pasted into a field expecting longitude and latitude.

Source: ESA SNAP Documentation

Resampling alone also does not guarantee that products from different tiles share one output grid. Start with acquisitions from the same tile; introduce reprojection and explicit grid alignment if the project requires broader coverage.

Define the calculation and outputs

Use BandMaths to create the NDVI band and a valid-pixel indicator. The next section defines the masking and reflectance checks that must accompany the formula.

For the first reviewed run, write a BEAM-DIMAP product so you can reopen it in SNAP and inspect its bands and metadata. Keep its .dim file and associated .data directory together. Generate the delivery GeoTIFF after validating this intermediate result.

Source: ESA SNAP Documentation

Replace fixed paths with parameters

Save the graph, then ask the assistant to replace its fixed input and output paths with placeholders. A graph fragment might contain:

<node id="Read">
  <operator>Read</operator>
  <sources/>
  <parameters>
    <file>${inputProduct}</file>
  </parameters>
</node>

<node id="Read">
  <operator>Read</operator>
  <sources/>
  <parameters>
    <file>${inputProduct}</file>
  </parameters>
</node>

Likewise, the Write node can use ${outputProduct} for its destination. These names are graph-defined parameters, not universal SNAP settings.

Source: Freie Universität Berlin

Keep the first graph narrowly scoped. Before adding batch logic, confirm that every node connects to the intended source, the required bands survive the subset, and the saved graph produces one readable output.

Handle Clouds, NoData, and Reflectance Correctly

The NDVI formula is simple:

For this workflow, NIR is B8 and red is B4. However, the expression should operate on correctly interpreted reflectance values, and only pixels passing the approved screening rules should contribute to the usable output.

Make the quality mask explicit

Sentinel-2’s Scene Classification Layer distinguishes clouds, cloud shadows, vegetation, water, snow, and other categories. It provides a starting point for screening, not a guarantee that every remaining pixel is uncontaminated.

Source: ESA SNAP Documentation

For this example, propose excluding NoData, saturated or defective pixels, cloud shadows, medium- and high-probability clouds, cirrus, and snow or ice. Review how to handle cast shadows and unclassified pixels for your study. Keep the final choices in the configuration rather than burying them in an unexplained expression.

Do not automatically exclude water simply because the output is NDVI. Negative values can be meaningful; whether water belongs in the analysis depends on the task.

Scene-level cloud percentage is useful for selecting products, but it does not tell you how much of your particular AOI remains usable. Calculate that proportion from the output mask.

Confirm scaling before calculating the index

Sentinel-2 L2A product metadata defines reflectance quantification and, where applicable, additive offsets. Ask the assistant to verify how the installed SNAP reader exposes those values to BandMaths.

Do not assume raw digital numbers are reflectance, and do not apply a correction twice. A shared multiplicative scale can cancel in a normalized ratio; additive offsets generally do not.

Finally, handle missing inputs and a zero denominator explicitly. Write excluded or undefined NDVI pixels as NoData, not zero. Preserve a separate valid-pixel mask so a genuine zero index remains distinguishable from an observation the workflow rejected.

Before continuing, inspect a small area containing clear land, clouds, and a boundary between them. Confirm that the mask and NDVI behave as intended.

Run One Product from the Terminal

Once the graph and masking rules are approved, run a single product through SNAP’s Graph Processing Tool. Start with a small AOI so problems appear before you commit to a larger run.

Source: Freie Universität Berlin

For a graph containing ${inputProduct} and ${outputProduct}, the PowerShell command follows this pattern:

Replace the example paths with your actual SNAP installation, graph, and product locations. Create the destination folder first. The -P names must match the placeholders defined in your XML; -e requests detailed error information.

Because this graph contains a Write node, configure the destination and format there. Do not assume a separate -t option will override it.

Capture the run with Python

A Python wrapper makes the command easier to record and repeat. Pass arguments as a list so paths containing spaces remain intact:

from pathlib import Path
import subprocess

gpt = Path(r"C:\Program Files\esa-snap\bin\gpt.exe")
graph = Path("graphs/masked_ndvi.xml").resolve()
source = Path("input/scene.SAFE/MTD_MSIL2A.xml").resolve()
target = Path("output/test/masked_ndvi.dim").resolve()
log = Path("logs/test-run.log")

target.parent.mkdir(parents=True, exist_ok=True)
log.parent.mkdir(parents=True, exist_ok=True)

if target.exists() or target.with_suffix(".data").exists():
    raise FileExistsError("Choose a new output location.")

command = [
    str(gpt), str(graph),
    f"-PinputProduct={source}",
    f"-PoutputProduct={target}",
    "-e",
]

from pathlib import Path
import subprocess

gpt = Path(r"C:\Program Files\esa-snap\bin\gpt.exe")
graph = Path("graphs/masked_ndvi.xml").resolve()
source = Path("input/scene.SAFE/MTD_MSIL2A.xml").resolve()
target = Path("output/test/masked_ndvi.dim").resolve()
log = Path("logs/test-run.log")

target.parent.mkdir(parents=True, exist_ok=True)
log.parent.mkdir(parents=True, exist_ok=True)

if target.exists() or target.with_suffix(".data").exists():
    raise FileExistsError("Choose a new output location.")

command = [
    str(gpt), str(graph),
    f"-PinputProduct={source}",
    f"-PoutputProduct={target}",
    "-e",
]

This wrapper calls an external executable. It does not import SNAP’s Python API, so it does not require esa_snappy.

Ask Claude or Codex to report the exit code and review the log without silently changing the graph after a failure. Even a zero exit code is only the first check: reopen the resulting .dim product in SNAP and confirm that its associated data directory, expected bands, and geographic coverage are present.

Process Multiple Dates Without Losing Track of the Results

After the first output passes review, extend the runner to a list of acquisitions. Keep the approved graph unchanged while varying the input product and output location.

Source: ESA SNAP Documentation

Use a manifest rather than asking the assistant to process every file it finds:

Have Claude or Codex extract acquisition dates, tile identifiers, and processing baselines from the product metadata into a separate inventory. Do not rely on the example identifiers above to establish which observations are comparable.

Give every product a traceable result

The batch runner should produce a summary with one row per input:

Start sequentially. Running several SNAP processes at once multiplies their memory and disk demands, so concurrency should be a later, measured adjustment.

Give the assistant a bounded instruction:

A file’s existence alone does not establish completion. A failed run may leave a .dim file or partially populated data directory.

Finally, consistent processing does not remove differences caused by season, illumination, atmospheric conditions, or remaining cloud contamination. Preserve those limitations when comparing dates, and record valid-pixel coverage so a mostly masked scene is not treated like a clear observation.

Validate the Raster Before Comparing Dates

A successful run can still produce an unusable raster. Open the processed product in SNAP Desktop and verify its spatial properties, pixel values, and quality mask before accepting it for comparison.

Use a short acceptance checklist:

Two rasters with the same CRS and nominal resolution are not necessarily aligned. Check their grid geometry before performing pixel-by-pixel differences.

Inspect the mask alongside the imagery

Compare an RGB view of the source product, the SCL layer, and the resulting NDVI. Look for cloud edges, shadows, unexpected gaps, or rectangular artifacts. A smooth color display can conceal those problems.

Review NDVI statistics over valid pixels only. Investigate nonfinite values and unexpected extremes rather than asking the assistant to clip everything into a reassuring range. Negative values are not automatically errors.

Source: ESA SNAP Documentation

For date comparisons, use consistent display limits. Independently stretched color scales can exaggerate or hide differences.

Finally, distinguish the analysis raster from a quicklook. A screenshot or colorized image is useful for review, but it does not replace a georeferenced raster containing the numerical values. After exporting the delivery GeoTIFF, reopen it and repeat the essential spatial and NoData checks; settings preserved in the working product should not simply be assumed to survive export.

Keep Larger Runs Stable

Before increasing batch size, identify what limits a representative run: processing time, available memory, or disk space. A larger workstation can provide more resources, but it will not correct an invalid graph or incomplete input.

SNAP’s GPT options distinguish tile cache (-c) from processing parallelism (-q). Tile cache is not total Java memory, and increasing threads does not guarantee faster execution.

Start with one process, leave memory for Windows and other applications, and measure before increasing concurrency. Adjust cloud workstation resources to the observed workload rather than assuming every operator benefits from a larger GPU.

Keep the computer running until processing and saving finish. Closing your viewing session and stopping the cloud computer are different actions.

Final Thoughts

The value of SNAP automation is a processing workflow you can inspect, repeat, and trust within its documented limits. Claude and Codex help prepare the graph, coordinate runs, and investigate failures. SNAP executes the operators, while you approve the scientific choices and validate the outputs.

Vagon Cloud Computer keeps those tools and datasets together in one accessible Windows workspace. Start with one verified product, preserve its graph and settings, and expand to multiple dates only after the results pass review.

FAQs

Do I need MCP to automate ESA SNAP?

No. This workflow runs SNAP’s command-line tool through reviewed commands or a Python wrapper. MCP is an optional integration layer, not a requirement.

Is SNAP’s gpt related to an AI language model?

No. Here, gpt means Graph Processing Tool. It executes SNAP operators and XML processing graphs.

Do I need esa_snappy?

Not for this workflow. Python launches the SNAP executable rather than importing the SNAP API. Direct API access through esa_snappy requires separate, version-compatible configuration.

Can I use this graph with Sentinel-1 radar imagery?

No. This example relies on Sentinel-2 reflectance bands and scene classification. Radar processing requires a graph designed for the specific product and analysis.

Does cloud masking make NDVI completely reliable?

No. Masks can miss contamination or exclude useful observations. Inspect the imagery, review valid-pixel coverage, and consider acquisition conditions before interpreting differences.

Will a larger GPU speed up every SNAP operation?

No. Acceleration depends on the operator and implementation. Measure CPU, memory, and storage demands before choosing resources or increasing parallelism.