Documentation for directAccess states the default is false, but it has defaulted to true since Parse Server 6

New Issue Checklist

• Report security issues confidentially.
• Any contribution is under this license.
• Before posting search existing issues.

Issue Description

The documentation for directAccess states that the option defaults to false, but it has defaulted to true since Parse Server 6. The contradiction sits inside a single JSDoc block, where the prose and the :DEFAULT: annotation disagree:

// src/Options/index.js
/* Set to `true` if Parse requests within the same Node.js environment as Parse Server should be routed to Parse Server directly instead of via the HTTP interface. Default is `false`.
<br><br>
If set to `false` then Parse requests within the same Node.js environment as Parse Server are executed as HTTP requests sent to Parse Server via the `serverURL`. …
<br><br>
⚠️ In environments where multiple Parse Server instances run behind a load balancer and Parse requests within the current Node.js environment should be routed via the load balancer and distributed as HTTP requests among all instances via the `serverURL`, this should be set to `false`.
:DEFAULT: true */
directAccess: ?boolean;

The true default is deliberate. It was announced as deprecation DEPPS2 and applied in Parse Server 6 (#8269). Only the prose was left behind, and it propagates: resources/buildConfigDefinitions.js copies it into src/Options/Definitions.js, which is what parse-server --help and the generated options documentation render. So every operator reading the documentation is told the opposite of what the server does.

The stale sentence is worse than a plain typo because of the ⚠️ paragraph directly beneath it. Deployments running multiple instances behind a load balancer are told they "should set this to false", while the sentence above assures them false is already the default. Those operators are the ones the warning is aimed at, and the documentation tells them no action is required, when in fact they need an explicit override.

For completeness, what the option controls: with directAccess enabled, ParseServer installs ParseServerRESTController as the SDK's REST controller.

// src/ParseServer.ts
if (process.env.PARSE_SERVER_ENABLE_EXPERIMENTAL_DIRECT_ACCESS === '1' || directAccess) {
  Parse.CoreManager.setRESTController(ParseServerRESTController(appId, appRouter));
}

That controller builds a request object and calls router.tryRouteRequest(method, path, request), so a Parse.Query in Cloud Code never traverses the Express stack and middleware mounted with app.use does not run for it. That is the intended design and the point of the feature. The issue is only that operators are told the mode is off by default, so they never get to weigh it.

Steps to reproduce

1. Run parse-server --help and read the directAccess entry, or open the generated options documentation.
2. Start Parse Server without setting directAccess and read the resolved value, for example Config.get(appId).directAccess.

Actual Outcome

The documentation says the default is false. The resolved value is true.

Expected Outcome

The documentation matches the behavior. Since the true default is intentional per DEPPS2, the fix is to the text, not the default: drop the "Default is false." sentence and state that the default is true, so the ⚠️ load-balancer guidance reads as an action rather than a reassurance.

Happy to open a PR.

Environment

Server

• Parse Server version: 9.10.1-alpha.6
• Operating system: macOS 15.5
• Local or remote host: local

Database

• System (MongoDB or Postgres): MongoDB
• Database version: 8.0
• Local or remote host: local

Client

• SDK (iOS, Android, JavaScript, PHP, Unity, etc): not applicable, server configuration
• SDK version: not applicable

Logs

No error is produced. The documented default is simply wrong.

Start in src/Options/index.js at the directAccess JSDoc block, then check how resources/buildConfigDefinitions.js copies it into src/Options/Definitions.js. Update the contradictory default wording and verify that the generated options documentation and parse-server --help state that the default is true.