tju-yxq opened a new issue, #2206:
URL: https://github.com/apache/rocketmq-dashboard/issues/2206

   ## Problem
   
   The CLI-backed AI providers launch `sh`, `claude`, and `qodercli` with 
`ProcessBuilder`. A new `ProcessBuilder` starts with a copy of the Studio JVM 
environment, and the current code only adds provider-specific entries:
   
   ```java
   Map<String, String> env = builder.environment();
   env.putAll(childEnv(config));
   ```
   
   The streaming Claude path follows the same pattern. As a result, every CLI 
subprocess receives unrelated server configuration that happens to be supplied 
through environment variables. Depending on the deployment, that environment 
can include the datasource password, Studio administrator password, Prometheus 
credentials, cloud credentials, or other container secrets. The subprocess only 
needs a small runtime environment plus the selected provider credentials.
   
   This is unnecessary secret exposure across a process boundary. It also makes 
the effective CLI contract depend on every variable present in the Studio 
container instead of an explicit set maintained by the AI provider layer.
   
   ## Expected behavior
   
   CLI subprocesses should start with an isolated environment by default:
   
   - retain only the runtime variables needed to locate and execute the CLI, 
find its user-scoped login state, create temporary files, use the configured 
locale, and honor explicitly supported proxy or CA settings;
   - add the selected provider's credential and endpoint variables after 
isolation, so those explicit values take precedence;
   - allow operators to opt in additional variable names for non-standard CLI 
installations without restoring inheritance of the complete server environment;
   - apply the same policy to availability probes, non-streaming completions, 
and Claude streaming;
   - never log inherited or provider-specific environment values.
   
   The default allowlist needs to preserve Qoder's user-scoped login state 
(`HOME`/XDG locations) and common outbound networking configuration, while 
excluding unrelated variables such as `SPRING_DATASOURCE_PASSWORD`, 
`STUDIO_AUTH_ADMIN_PASSWORD`, arbitrary access keys, and `NODE_OPTIONS`.
   
   ## Proposed implementation
   
   Introduce a dedicated CLI process-environment policy rather than duplicating 
`clear()`/copy logic at each launch site. The policy should:
   
   1. build a fresh environment from a documented, immutable default allowlist;
   2. accept a configured list of additional variable names;
   3. copy values only from the current Studio environment for those approved 
names;
   4. overlay the provider-specific environment last;
   5. replace the `ProcessBuilder` environment atomically before `start()`;
   6. be shared by `CliAgentProvider.available()`, 
`CliAgentProvider.complete()`, and `ClaudeCodeAgentProvider.stream()`.
   
   The complete fix is expected to exceed 100 lines of production code because 
it requires a reusable policy with configuration and validation, plus 
integration at all three subprocess boundaries. The size should come from the 
complete isolation contract, not from duplicating launch code.
   
   ## Test coverage
   
   Add deterministic unit tests that construct a representative parent 
environment and verify that:
   
   - required path, home, temporary-directory, locale, proxy, and CA variables 
are retained;
   - arbitrary server secrets are removed;
   - configured extra names are retained without exposing other variables;
   - provider values override an inherited value with the same name;
   - invalid or blank configured names are ignored safely;
   - availability, completion, and streaming launch paths all use the same 
isolated policy.
   
   The tests should inspect the constructed child environment directly or 
execute a controlled local test subprocess. They should not depend on 
credentials or secrets from the developer machine.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to