The problem
When a user runs a custom geoprocessing tool and clicks Copy Python Command, ArcGIS Pro copies only the raw call, for example:
arcpy.mytools.MyTool(in_features=..., out_features=..., ...)
For system tools this works, because system toolboxes are always loaded into arcpy. But for any custom toolbox — a project toolbox, a stand‑alone .pyt, or one delivered inside an add‑in — that toolbox's alias is not in the arcpy namespace until arcpy.ImportToolbox() has been called. Because the copied text leaves that line out, pasting it fails immediately with:
AttributeError: module 'arcpy' has no attribute 'mytools'
In other words, the one button most users reach for to script a tool they just ran produces code that cannot run.
What happens now
- System tool → Copy Python Command → pastes and runs.
- Custom tool → Copy Python Command → fails on paste, because the required arcpy.ImportToolbox(...) line (and import arcpy) is omitted.
- For add‑in‑delivered toolboxes the failure happens even in Pro's own Python window, because such a toolbox is never added to the project and so is never auto‑imported.
- Pro's separate "Save as Python script" workflow does emit an import line, but it is a different, less‑discoverable path — and there are outstanding reports that the ImportToolbox line it generates itself errors — so it is not a dependable substitute.
Why it matters
Every user who copies the Python command from a third‑party or organizational tool hits an error and assumes the tool, or their install, is broken. This generates avoidable support requests and undermines confidence in tools that actually work perfectly. It also defeats the whole purpose of the button: run a tool interactively, then script it. Custom Python toolboxes are a first‑class extensibility path for ArcGIS Pro, yet the primary way to script them is broken out of the box, with no clean fix available to developers.
Proposed solution
When Copy Python Command is used for a tool in a non‑system toolbox, prepend the statement needed to make the copied code runnable, using the toolbox path and alias Pro already knows at that moment (it just executed the tool):
arcpy.ImportToolbox(r"<resolved absolute path to the .pyt or .atbx>")
arcpy.mytools.MyTool(in_features=..., out_features=..., ...)
Specifically:
1. Emit arcpy.ImportToolbox(r"…") with the resolved on‑disk path of the toolbox, immediately before the tool call, for any custom (non‑system) toolbox — including add‑in‑delivered toolboxes.
2. Use the toolbox's own alias, so the existing arcpy.<alias>.<Tool>() call resolves after the import.
3. Leave system tools unchanged — no import line for them (fully backward compatible).
4. Optionally, gate this behind a setting (Options → Geoprocessing: "Include import statements when copying Python commands", on by default for custom tools) and/or also prepend import arcpy for the Notebook and stand‑alone cases.
5. Please also make the "Save as Python script" path emit a correct, resolvable ImportToolbox for custom .pyt tools, so both paths are consistent and reliable.
This is the natural next step after the already‑shipped improvement that added parameter names to Copy Python Command (ArcGIS Pro 3.1). Adding the import line is the remaining piece that makes the copied command genuinely runnable for the growing ecosystem of custom and third‑party Python toolboxes.
