Orchestration hierarchy passes wrong permission flag to Qwen/Gemini

Hi anh Khoa,
Detail log via link: https://drive.google.com/file/d/1p7LTBRX6euY0VmBHM5TD_76LLiHT1gsf/view?usp=sharing
I found a bug in the Orchestration hierarchy/pipeline preset when the preset contains different agentKind values, specifically Qwen (and likely Gemini).

Symptom

When I use Add Terminal → Orchestration with a hierarchy preset such as:

• QWEN lead
• Profile CLAUDE-QWEN-CODEX-AGY

the Claude/Codex/Agy nodes receive their injected brief/prompt normally.

However, the agentKind=qwen node does not receive any prompt. The terminal starts /mcp and then appears to stay idle.

Evidence from 1DevTool logs

I exported the official run log from:

runs/c9f18aec-dc44-45d8-b1a4-448f7e3bbadb/

meta.json shows:

target="qwen"
command="1devtool-agent run --to=qwen"
status="error"
exitCode=1
durationSeconds=0

The first error in stderr.txt is:

Unknown arguments: dangerously-skip-permissions, dangerouslySkipPermissions

followed by the Qwen help output.

Independent reproduction

I reproduced the exact same behavior directly with Qwen, outside 1DevTool:

qwen -p "reply PONG" --dangerously-skip-permissions

→ crashes with the same Unknown arguments error.

But:

qwen -p "reply PONG" --approval-mode=yolo

→ works correctly and returns the response.

I also tested Gemini:

gemini -p "reply PONG" --dangerously-skip-permissions

→ same argument parsing error.

Whereas:

gemini -p "reply PONG" --approval-mode=yolo

→ argument parsing succeeds. The subsequent error is only related to my Gemini account eligibility and is unrelated to this issue.

Possible root cause

I inspected the app.asar and noticed that 1DevTool already has per-agent permission flag mappings in at least two places.

For example:

qwen     → --approval-mode=yolo
gemini   → --approval-mode=yolo
kimi     → --yolo
grok     → --always-approve
cursor   → --force
amp      → --dangerously-allow-all
opencode → --dangerously-skip-permissions
agy      → --dangerously-skip-permissions
claude   → --dangerously-skip-permissions

So it looks like the application already handles the agent-specific flags correctly elsewhere.

My suspicion is that the Orchestration hierarchy/pipeline headless launch path:

1devtool-agent run --to=

is bypassing that existing mapping and hardcoding:

--dangerously-skip-permissions

for every agentKind.

That would explain why Qwen exits with exitCode=1 and durationSeconds=0 before the prompt can ever be injected.

Suggested fix

Could you check whether the hierarchy/pipeline launcher can reuse the existing per-agentKind permission flag mapping instead of hardcoding --dangerously-skip-permissions?

In particular:

qwen   → --approval-mode=yolo
gemini → --approval-mode=yolo

while keeping the existing flags for Claude/Agy/OpenCode/etc.

I believe this is why the Qwen node currently starts the terminal but never receives the orchestration brief.

Qwen is confirmed from both the official 1DevTool run log and an independent CLI reproduction.

Gemini appears to have the same issue, although I have not yet confirmed the Gemini node through the hierarchy path itself.

Hopefully this helps narrow down the issue. The evidence points specifically to the orchestration/headless launch path rather than a Qwen or Gemini CLI problem.

Thanks!