Before submitting
Area
apps/desktop
Problem or use case
I want to use Factory's Droid CLI as a coding-agent backend inside DP Code, the same way DP Code can already work with providers like OpenCode, Codex etc.
Today, users running Factory/Droid need to run Droid separately in a terminal instead of managing those sessions through DP Code's desktop UI. That means losing all of DP Code's unique UI features
Droid appears to fit DP Code's agent model because it supports non-interactive execution through droid exec, model selection, autonomy settings, session continuation, and structured output formats, etc.
Proposed solution
Add Factory Droid CLI as a new provider, likely named droid or factoryDroid.
A first version could add:
- Provider support alongside Codex, Claude, Gemini, and OpenCode.
- Droid model options for model ID and autonomy level.
- Support for custom BYOK models configured by the user in the Droid config
- UI support so Droid appears in the provider/model picker.
The initial CLI mapping could use Droid's non-interactive mode:
droid exec \
--model <model-id> \
--auto <low|medium|high> \
--output-format stream-jsonrpc \
"<user prompt>"
Why this matters
This would make DP Code useful for users and teams that already rely on Factory Droid for coding-agent workflows.
Instead of switching between DP Code for some providers and a separate terminal for Droid, users could keep a consistent workflow across providers: choose a project, select a model/provider, start a thread, review activity, and manage the session from the same UI.
Smallest useful scope
- Add support for Droid as an agent, stream output, and expose basic model/autonomy options; and most features that are found in the CLI
- Support user-configured BYOK models defined in the Droid config.
Contribution
Before submitting
Area
apps/desktop
Problem or use case
I want to use Factory's Droid CLI as a coding-agent backend inside DP Code, the same way DP Code can already work with providers like OpenCode, Codex etc.
Today, users running Factory/Droid need to run Droid separately in a terminal instead of managing those sessions through DP Code's desktop UI. That means losing all of DP Code's unique UI features
Droid appears to fit DP Code's agent model because it supports non-interactive execution through
droid exec, model selection, autonomy settings, session continuation, and structured output formats, etc.Proposed solution
Add Factory Droid CLI as a new provider, likely named
droidorfactoryDroid.A first version could add:
The initial CLI mapping could use Droid's non-interactive mode:
Why this matters
This would make DP Code useful for users and teams that already rely on Factory Droid for coding-agent workflows.
Instead of switching between DP Code for some providers and a separate terminal for Droid, users could keep a consistent workflow across providers: choose a project, select a model/provider, start a thread, review activity, and manage the session from the same UI.
Smallest useful scope
Contribution