ShareX Custom Action Not Running: How to Fix It

A ShareX custom action can fail in several confusing ways: nothing appears to happen, the external program opens without the captured file, the command receives an incomplete path, or a console window flashes and disappears. These symptoms usually come from one of five areas: an incorrect executable path, malformed arguments, the wrong action timing, a missing working directory, or Windows blocking the process. The steps below focus specifically on external custom actions and commands, not ShareX's built-in save, upload, copy, or notification tasks.

Start with the smallest possible test instead of changing multiple settings at once. Once a simple external action runs successfully, add your real program, arguments, upload dependencies, or script logic back one piece at a time. This approach shows exactly where the workflow breaks and helps you avoid disrupting settings that already work.

1. Confirm the Symptom and Reproduce It With a Simple Test

Before editing the action, determine whether ShareX is failing to launch the command or whether the external program launches and then fails. Those are different problems. If no process or window appears, inspect the action path, trigger timing, and Windows permissions first. If the program opens but does not receive the expected image or recording, focus on arguments, quotation marks, and the file state at the time the action runs.

1.1 Replace the real command temporarily

Configure a temporary action that launches a basic Windows application, such as Notepad. Use the full path to the executable rather than relying on Windows to locate it. On a typical installation, the executable is available at C:\Windows\System32\notepad.exe. For the first test, leave the argument field empty.

Run the same type of ShareX task that is supposed to activate the action. For example, take a region screenshot if the action normally runs after a screenshot. Success means Notepad opens after that task. At that point, stop changing the ShareX trigger because the trigger and basic process launch are working. Move on to testing the real executable and its arguments.

If Notepad does not open, confirm that the action is enabled for the task you are performing. An action configured correctly but not included in the active after-capture or after-upload workflow will appear completely silent.

1.2 Test file delivery separately

After confirming that ShareX can launch an application, test whether it can pass the captured file. A convenient test is to use a small batch script that writes every received argument to a text file. For example, create a file named sharex-action-test.cmd with content similar to:

@echo off
echo %date% %time% >> "%USERPROFILE%\Desktop\sharex-action-test.txt"
echo Argument 1: %~1 >> "%USERPROFILE%\Desktop\sharex-action-test.txt"
pause

Set the action path to the script and pass the ShareX file-path token used by your action configuration as the first argument. ShareX interfaces and action configurations can differ, so select or copy the file-path placeholder shown by your installed application rather than guessing its spelling.

Success means the text file is created and contains the complete expected path. If the script runs but the argument is blank, the selected trigger may not provide a local file at that stage, or the wrong placeholder is being used. If the path stops at the first space, its quotation marks need correction.

2. Check the ShareX Settings Directly Related to This Problem

2.1 Verify the action path

The action path should point to a real executable, script, or command processor. Browse to the file when possible instead of typing the path manually. Watch for moved portable applications, renamed folders, disconnected drives, and commands copied from another computer.

If the action runs a batch file, PowerShell script, Python script, or another interpreted file, launching the interpreter explicitly is often more reliable. Set the executable field to the appropriate interpreter and place the script path in the arguments. For a batch file, that may mean launching cmd.exe with the batch file as an argument. For PowerShell, use the installed PowerShell executable and pass the script with the appropriate file parameter.

Do not put the executable and all of its arguments into the executable-path field unless the action interface specifically expects one complete command line. Keep the program path and argument string in their designated fields. Success means the intended process appears and remains open long enough to complete its work.

2.2 Quote every path that can contain spaces

Windows command lines use spaces to separate arguments. A path such as C:\Users\Alex Smith\Pictures\Screen Shot.png can therefore be split into several pieces unless it is enclosed in straight double quotation marks.

Quote the script path, captured-file placeholder, output folder, and any other path-like value. A typical argument pattern is conceptually similar to "captured file path" "output folder". Use the exact ShareX placeholder provided in your action editor in place of the descriptive text.

Avoid curly quotation marks copied from formatted documents. They may look correct but are not command-line delimiters. Type ordinary straight quotes in ShareX. Success means the test script or external application receives one complete path, including its filename and extension.

2.3 Set a dependable working directory

The working directory is the folder from which the process starts. It is not necessarily the folder containing the executable, script, or captured image. This distinction matters when a script uses relative paths such as .\config.json, output\result.txt, or a helper executable named without its full location.

Set the working directory to the folder containing the script or program when that program expects nearby files. Alternatively, revise the command so every dependency and destination uses an absolute path. The second option is generally more portable and easier to diagnose.

Success means the action can find its configuration files, helper programs, and output folders regardless of where ShareX itself was started. Once relative-path errors disappear, stop changing the working directory.

2.4 Choose the correct workflow stage

An action configured to run after capture receives a different workflow state from one that runs after upload. After capture is appropriate when the external tool needs the local screenshot, recording, or processed file. After upload is appropriate when the command needs the resulting URL, upload response, or destination-specific data.

If your external program expects a local file, make sure that a file actually exists when the action runs. A clipboard-oriented capture workflow may not save a permanent file in the location your command expects. If the command expects a URL, running it before the upload finishes will produce an empty or unavailable value.

Success means the action receives the kind of input it was designed to process. After reaching that result, do not enable the action at multiple stages unless you intentionally want duplicate executions.

3. Check Windows and Workflow Factors

3.1 Test permissions without making permanent security exceptions

Windows can prevent a custom action from starting or writing output even when ShareX itself captures normally. This can happen when the executable is downloaded and marked as untrusted, when the destination folder is protected, or when antivirus software blocks an unfamiliar script or command-line pattern.

Check Windows Security protection history and your security product's event records immediately after reproducing the problem. Verify that the script or executable came from a trusted source before unblocking or allowing it. Do not disable antivirus protection globally merely to test an automation command.

Also avoid mixing privilege levels unnecessarily. A program that requires administrator rights may display a User Account Control prompt or fail when launched non-interactively. As a diagnostic test only, compare behavior when ShareX and the target program run at compatible privilege levels. The better long-term fix is usually to remove the target program's unnecessary administrator requirement.

Success means the action launches under your normal Windows account and writes only to the intended destination. Once it does, stop adjusting security settings and retain the narrowest permission change possible.

3.2 Confirm that the destination exists and is writable

An action may run correctly but fail while writing its result. Check that the output folder exists, the drive is connected, and the current user can create a normal text file there. For network shares, confirm that the mapped drive or UNC location is available in the same user session.

Cloud-synced, removable, and network folders introduce extra timing and availability variables. Temporarily direct output to a simple local folder under your user profile. If that works, the action itself is sound and the original destination is the problem.

Success means a predictable output file appears in the temporary local folder. At that point, investigate access to the original destination rather than continuing to edit ShareX arguments.

3.3 Keep console windows open during diagnosis

A console window that flashes and closes usually means the process started but ended quickly. That is useful evidence, not the same symptom as a command that never launched. Run the exact generated command in Command Prompt or PowerShell so its output remains visible.

For a temporary batch-file test, add pause at the end. Another option is to redirect standard output and errors to a log file using shell redirection. Remove diagnostic pauses after fixing the problem because they can leave hidden or unwanted windows waiting for input.

Success means you can read the actual error, such as an unrecognized option, missing file, unavailable module, or access-denied message. Fix that specific error before changing unrelated ShareX settings.

3.4 Account for capture, recording, upload, and destination timing

Screen recordings may not be finalized until encoding stops, so an action cannot safely process the completed file while recording is still active. Upload-dependent actions also need a successful destination response before a URL exists. OCR and image-editing steps can change which content or file is available later in the workflow.

Reproduce the issue with the simplest matching task. Use a normal screenshot for an image action, a short completed recording for a video action, and a known working destination for an upload-dependent action. This separates action failure from capture, encoder, network, authentication, or destination failure.

4. Run a Clean Temporary Test With Minimal ShareX Settings

Create a temporary diagnostic action rather than dismantling your working automation. Disable that test action when finished. The goal is to establish a known-good chain with one trigger, one executable, one argument, and one local output.

1. Choose a basic screenshot capture that finishes immediately.
2. Configure one temporary external action and disable unrelated custom actions for the test.
3. Launch Notepad with no arguments to verify process execution.
4. Replace Notepad with the argument-logging batch script.
5. Pass only the local captured-file placeholder in straight double quotes.
6. Write the diagnostic result to a simple local folder.
7. Add the real executable, options, and destination one at a time.

After each step, repeat the same capture. Do not make several changes between tests. When the first failure returns, the last addition identifies the likely cause. For example, if the action works until you add an output-folder argument, inspect that folder's quoting, existence, and permissions.

A clean test is successful when one screenshot causes exactly one action execution, the complete local path reaches the script, and the expected output appears. Preserve that working configuration as a reference while repairing the original action.

5. Check Task History, Logs, and Recent Output

ShareX task history can reveal whether the capture, file creation, processing step, or upload completed before the external action was expected to run. Open the latest matching task rather than an older task with a similar filename. Look for failure messages, missing output, or evidence that the workflow stopped before reaching the action.

If the external program creates its own log, compare its timestamp with the ShareX task. No new external log suggests the program never started or could not initialize. A fresh log containing a file-not-found or invalid-argument error shows that ShareX launched it and the remaining problem belongs to the command line or external program.

When asking for help, include the trigger stage, executable type, sanitized argument pattern, working directory, expected input, and exact error text. Redact your Windows username if necessary, along with API keys, upload tokens, private URLs, server names, customer data, and sensitive filenames. Replace secret values consistently so the command structure remains understandable.

Do not post an entire configuration file or log without reviewing it. ShareX workflows can involve destination credentials and private upload responses. A short, sanitized excerpt around the failure is safer and usually more useful.

6. Quick Fix Checklist

• Confirm the external action is enabled for the task you are actually running.
• Browse to the executable and verify that the file still exists.
• Keep the executable path separate from its arguments.
• Use straight double quotes around every path that may contain spaces.
• Use the exact local-file or URL placeholder offered by ShareX.
• Run file-based commands after the local file is available.
• Run URL-based commands only after a successful upload.
• Set the working directory when the script relies on relative files.
• Test output in a writable local folder before using a network destination.
• Inspect Windows Security protection history for a blocked process.
• Use a temporary script to record the arguments ShareX sends.
• Run the command manually to keep errors visible.
• Check the newest task history entry for earlier workflow failures.
• Change one setting at a time and stop when the expected output appears.

7. Frequently Asked Questions

7.1 Why does my ShareX custom action do nothing?

The most common explanations are that the action is not enabled for the active workflow, the executable path is wrong, Windows blocked the process, or the workflow never reached the selected trigger stage. Test with Notepad and no arguments. If Notepad opens, ShareX can launch external processes and you should inspect the real command and its arguments.

7.2 Why does the action receive only part of the file path?

The path probably contains spaces and is not enclosed in straight double quotation marks. Quote the entire ShareX file-path placeholder in the arguments field. Verify the result with an argument-logging script rather than relying on what the target program displays.

7.3 Should the action run after capture or after upload?

Use after capture when the command needs the local screenshot, recording, or processed file. Use after upload when it needs an uploaded URL or destination response. If both are required, test each stage separately and make sure the program is prepared to receive the correct input type.

7.4 Why does a command work manually but not from ShareX?

Your terminal may provide a different working directory, environment, privilege level, or command search path. Use absolute paths for the executable, script, dependencies, and destination. Set an explicit working directory if the program requires one, and test under the same Windows account and privilege level used by ShareX.

7.5 How can I see an error before the console closes?

Run the exact command manually in an existing Command Prompt or PowerShell window. For a temporary batch script, add pause or redirect output and errors to a text file. Remove the pause after diagnosis so unattended actions can finish normally.

7.6 When should I stop changing ShareX settings?

Stop when the action runs once at the intended stage, receives the complete expected input, and creates the expected output. If a minimal ShareX test works but the real program still fails, troubleshoot that program, its command syntax, dependencies, permissions, or destination. Continuing to change unrelated capture, clipboard, editor, or upload settings can turn one isolated problem into several.