Forge Command-Line Arguments

For the source/Git route, edit COMMANDLINE_ARGS in the active webui-user.bat and launch that file. The official Windows archive has an outer package layer; inspect its run.bat first and confirm which inner launcher it calls before editing a similarly named file.

Set export COMMANDLINE_ARGS="..." in webui-user.sh, then start Forge through webui.sh so that user file is sourced. Do not edit webui.sh for a normal persistent argument.

Put the flags on the same COMMANDLINE_ARGS value separated by spaces. Quote each value that contains spaces. Add one new flag per test so the result still identifies a cause.

Quote the value, not the flag: --ckpt-dir "D:\AI Models\Stable-diffusion". Then confirm the complete path appears as one value in the launch line and no “unrecognized arguments” fragment remains.

Read the console line beginning “Launching Web UI with arguments”. Save that line with the commit and environment receipt. A value written in a dormant launcher file is not evidence that the running process received it.

The flag may be misspelled, copied from reForge/Neo/Classic, supplied by a missing third-party extension, or broken into extra tokens by incorrect quoting. Compare it with this commit-bound core inventory and the active extension preloads.

No. It proves only that the current parser recognizes the name. Eleven entries explicitly say they do nothing, and several inherited A1111 controls have partial or separate consumers in current Forge.

--listen changes network binding, --share requests a Gradio public tunnel, and --api enables API routes. They solve different jobs, can be combined, and each changes the security boundary beyond a default localhost-only UI.

It makes Forge respond to network requests but does not supply a complete deployment security design. Review firewall scope, authentication, allowed paths, API settings, sensitive outputs, and every extension before exposing it.

Not as a generic fix. It disables a malicious-code safety check for PyTorch model loading. Verify the model format and source instead of weakening the control for an unknown file.

No. A flag cannot turn non-finite tensors into a valid image. At the inspected commit the relevant test function returns before using this inherited flag, so it is retained as a stale compatibility surface.

Only when you already understand why the test is wrong for that exact environment. Skipping it does not repair Torch, the driver, CUDA runtime, or an unsupported GPU; it can merely defer the failure.

Do not begin with all three. The dated maintainer note describes potential gains and specific crash, black-output, and OOM risks. Add one change to a recorded baseline, repeat the same job, and retain a rollback.

They remain in the inherited parser, but current Forge has its own backend memory manager and runtime memory controls. Do not assume an old A1111 recipe controls the complete Forge path; use the dedicated memory guide and verify the actual device trace.

--disable-extra-extensions keeps built-ins while blocking third-party extensions. --disable-all-extensions blocks both. Start with extra for extension isolation, then use all only when a built-in must also be tested.

--data-dir moves the broad user-data base, including default settings, outputs, user extensions, cache, and models. --models-dir replaces only the models base. Use the paths reference before moving either.

At this commit the parser help explicitly calls eleven entries no-op or legacy: max-batch-count, always-batch-cond-uncond, unload-gfpgan, ngrok-region, deepdanbooru, show-negative-prompt, both old Gradio tool flags, enable-console-prompts, gradio-queue, and add-stop-route.

Yes. Forge preloads enabled user extensions and built-ins before its final parse. This page inventories the clean Original Forge core and its built-ins; extension-specific flags belong to the exact extension and commit that defines them.

launch_utils checks the literal token before the final parser, but the inspected core parser does not register it with add_argument. It is documented here as a special internal token, not counted as a normal core argument.

No. Those are separate repositories with different parsers and behavior. Copy only a flag verified in the exact Original Forge commit you run, then add it to a clean baseline one at a time.