Feature Request: External Agentic Node (Claude Code / Codex Integration)

Summary

Add a new node type that allows Dify workflows to delegate tasks to external high-capability agentic CLI tools like Claude Code, OpenAI Codex, Cursor Agent, or similar. These tools represent a higher level of autonomous problem-solving capability compared to traditional LLM + Tools combinations.

Motivation

Currently, Dify's Agent Node uses a model + strategy (ReAct, Plan-and-Execute) + tools approach. While powerful, it has limitations:

1. Limited autonomy: The agent is constrained to predefined tools and workflows within Dify
2. No file system / code execution: Cannot perform complex operations like editing files, running tests, debugging
3. No multi-step reasoning: Tools are invoked one at a time; no persistent "working session"
4. No IDE integration: Cannot leverage the full power of tools like Claude Code that understand project context

External agentic CLI tools like Claude Code (Anthropic) and OpenAI Codex offer:

• Full autonomous coding: read, write, edit, test, debug
• Project-level context awareness (reads CLAUDE.md, AGENTS.md, .cursorrules)
• Multi-step task execution with self-correction
• Shell command execution
• Git operations, PR creation
• Deep reasoning over complex tasks

Proposed Solution

New Node Type: "External Agent Node" (or "Agentic CLI Node")

Node Configuration:

Node Type: External Agent
Provider: [Claude Code | OpenAI Codex | Custom CLI]
Task Prompt: {{input_task}}
Working Directory: [optional path or container mount]
Context Files: [optional list of files to provide]
Timeout: [max execution time]
Output Format: [text | structured JSON]

Execution Flow:

1. Dify sends a task prompt to the external CLI via subprocess
2. The CLI agent autonomously works on the task (may iterate, use tools, edit files)
3. Final result returned to Dify workflow
4. Optional: capture intermediate steps for observability

Example Use Cases:

Implementation Options:

1. Subprocess-based (simplest):

   • Dify calls claude --print "task" or codex "task" via subprocess
   • Captures stdout as result
   • Requires the CLI to be installed on the Dify server

2. API-based (more cloud-friendly):

   • Claude Code has an experimental HTTP API mode
   • OpenAI Codex has API endpoints
   • Dify sends HTTP request, receives streamed result

3. Plugin architecture:

   • Create a new "External Agent Plugin" type
   • Each provider (Claude Code, Codex) implements the interface
   • Marketplace distribution

Technical Considerations

1. Security: External agents can execute shell commands. Need:

   • Sandbox/container execution
   • Permission controls
   • Audit logging

2. Timeouts: Complex tasks may take minutes. Need:

   • Progress streaming (partial results)
   • Timeout configuration per node
   • Background execution mode

3. Cost: External agents consume API credits. Need:

   • Cost estimation before execution
   • Usage tracking
   • Budget limits

4. Output parsing: Agents return text, not structured JSON. Need:

   • Prompt engineering for structured output
   • Post-processing to extract key results

Alternatives Considered

1. HTTP Request Node + MCP: Can call an MCP server that wraps Claude Code, but:

   • Requires custom MCP server development
   • No native integration with Dify's variable system
   • Limited observability

2. Tool Node: Add Claude Code as a "Tool", but:

   • Tools are single-call, not multi-step agents
   • No support for autonomous iteration

3. Custom Code Node: Use Python to call the CLI, but:

   • Requires coding knowledge
   • No UI configuration
   • Harder to maintain

Additional Context

• Claude Code: https://github.com/anthropics/claude-code
• OpenAI Codex: https://github.com/openai/codex (CLI tool, not the API)
• Related Dify docs: https://docs.dify.ai/guides/workflow/node/agent

Acceptance Criteria

1. New node type appears in Dify node palette
2. Configuration UI for provider selection, prompt input, timeout
3. Execution logs show intermediate agent steps
4. Result returned to downstream nodes as variable
5. Works for both cloud and self-hosted Dify

Would the Dify team consider this feature? I'm happy to contribute to the implementation if this aligns with the roadmap.