Skip to content

feat: add Cline CLI integration as a compatible tool#47

Open
Solar2004 wants to merge 3 commits into
aannoo:mainfrom
Solar2004:feat/cline
Open

feat: add Cline CLI integration as a compatible tool#47
Solar2004 wants to merge 3 commits into
aannoo:mainfrom
Solar2004:feat/cline

Conversation

@Solar2004

Copy link
Copy Markdown

Summary

Add Cline as a supported AI coding CLI in hcom (like Claude, Gemini, Codex, OpenCode, Kilo). Includes Tool enum, LaunchTool, PTY launcher, embedded hook scripts, config support, help entries, status checks, TUI support, and integration tests.

Changes

  • Tool::Cline variant in src/tool.rs
  • Full hook lifecycle in src/hooks/cline.rs with auto-ack
  • src/tools/cline_preprocessing.rs — preprocessing
  • Hook scripts in src/opencode_plugin/ (TaskStart, TaskComplete, etc.)
  • Integration tests in tests/test_pty_delivery.rs

Note: This PR depends on Kilo being merged first (shared infrastructure in Tool enum cycling and launcher match arms).

Solar2004 added 3 commits May 8, 2026 21:28
- Add Kilo enum variant to tool.rs with kilo-start/status/read/stop hooks
- Create hooks/kilo.rs with full lifecycle handlers (start, status, read, stop)
- Create tools/kilo_preprocessing.rs for hcom bash auto-approval env vars
- Add LaunchTool::Kilo to launcher.rs with PTY dispatch and plugin check
- Add kilo to bootstrap.rs spawn list and delivery auto-check
- Add kilo_args field to config.rs with HCOM_KILO_ARGS env and [launch.kilo] toml
- Add kilo to router.rs LAUNCH_TOOLS and hook dispatch
- Add kilo to commands/launch.rs preview and arg merging
- Create hcom_kilo.ts plugin (kilocode-specific adaptation of hcom.ts)
- Handle cross-agent merge conflicts with KiloCode naming
Add Cline as a supported AI coding CLI in hcom (like Claude, Gemini, Codex,
OpenCode, Kilo). Includes Tool enum, LaunchTool, PTY launcher, embedded
hook scripts, config support, help entries, status checks, TUI support,
and integration tests.
@aannoo

aannoo commented May 25, 2026

Copy link
Copy Markdown
Owner

good idea but looks like would work better if was closer to how claude/codex work than the opencode plugin thing

AI review:

PR #47 - Cline Integration

Branch: feat/cline

Approximate size: +3,228/-73, 38 files

Note: PR description states this stacks on PR #45. If PR #45 is reshaped (per its own review), the shared scaffolding this PR reuses will not exist in that form, and this PR will need to be rebased onto a Cline-specific shape regardless of the issues below.

Verdict

Do not merge as-is.

Cline support is a reasonable goal, but this PR installs hooks where Cline does not read them, routes delivery through the wrong model, advertises resume/fork without implementing Cline semantics, and accidentally removes OpenCode PTY coverage. The right shape is PTY launch plus runtime-injected Cline hooks, not an OpenCode-style plugin path.

What The PR Adds

  • Cline hook scripts and Rust handlers.
  • Cline launch/help/TUI wiring.
  • OpenCode-like delivery assumptions.
  • Cline help specs claiming resume/fork support.

Blockers

  1. Hooks are installed in the wrong place.

    Per upstream cli/src/core/hooks/utils.ts, Cline reads global hooks from ~/Documents/Cline/Hooks/ and workspace hooks from <workspace>/.clinerules/hooks/, and exposes --hooks-dir <path> per cli/src/index.ts for runtime injection. The PR installs to $XDG_CONFIG_HOME/cline/hcom/ (src/hooks/cline.rs::get_cline_plugin_dir) and scans five additional variants under $XDG_CONFIG_HOME/cline/ and .cline/. None match Cline's load paths, and the PR does not pass --hooks-dir at launch.

  2. Wrong delivery model.

    Cline is a stateless hook-script bridge plus TUI. OpenCode is a long-lived plugin transform. src/delivery.rs:336 maps Tool::Cline => Self::opencode(), and src/delivery.rs:614 adds Tool::Cline to the OpenCode-mode early-exit. The delivery thread exits after the first message, expecting a plugin to take over — Cline has no plugin to take over. The PR ships five Cline lifecycle hooks (TaskStart, TaskResume, TaskComplete, TaskCancel, UserPromptSubmit) and does not ship PostToolUse, which is the in-turn pickup hook Claude uses. Only UserPromptSubmit fires inbound — i.e. on the next user prompt.

  3. Bootstrap/delivery labels disagree.

    src/bootstrap.rs:415 adds cline to neither the DELIVERY_AUTO branch nor an explicit fallthrough. The agent reads DELIVERY_AUTO semantics in some surfaces and gets DELIVERY_ADHOC behavior in delivery. One of those surfaces is lying.

  4. ready_pattern does not match Cline's TUI.

    src/tool.rs:74 sets Tool::Cline => b"ctrl+p commands". That string is OpenCode's TUI footer; Cline's TUI is React-Ink based and does not display it. The PTY ready gate will not fire. Reviewers should confirm against a running Cline TUI before merging.

  5. Fragile shell JSON parsing.

    Hook scripts parse JSON with sed/awk regexes. Any escaped quote, embedded "," pattern in bootstrap text, or multi-line JSON breaks the parse. The response being parsed is generated by hcom itself (serde_json::to_string in src/hooks/cline.rs); a Rust subcommand or jq would be safer.

  6. Initial prompt uses a --prompt flag that may not exist.

    src/launcher.rs:899-901 appends --prompt for Cline with the comment "(same as opencode)". Per cline/cli/src/index.ts, Cline's main command takes a positional [prompt], plus cline task <prompt> and --taskId <id>; --prompt is not in the documented flag set. Confirm by running cline --help against the targeted Cline version.

  7. Resume/fork is advertised but not implemented.

    CLINE_SPEC and CLINECODE_SPEC set has_fork = true. src/commands/resume.rs has no Cline case and no build_resume_args for it. Cline resumes via --taskId <id>, not OpenCode's --session.

  8. OpenCode PTY coverage is lost.

    tests/test_pty_delivery.rs:1451 renames test_pty_opencode to test_pty_cline. run_pty_test_opencode at line 844 remains in the file but no #[test] calls it. Cline gains a test; OpenCode loses one. Net coverage change is negative on a tool this PR does not intend to touch.

  9. Released tool surfaces drift.

    src/shared/constants.rs::RELEASED_TOOLS = &["claude", "gemini", "codex", "opencode", "kilocode"]. Cline is not in the list but is wired into command/help/TUI cycles elsewhere in the PR. It appears launchable in one UI path and absent in another.

  10. Orphan duplicate script.

    src/opencode_plugin/clinehook.sh is nearly byte-identical to TaskStart (single-character comment difference) and is not referenced from PLUGIN_FILES.

What To Keep

  • Cline integration is worth doing.
  • --hooks-dir is the natural integration point.
  • Cline should probably be a PTY-launched tool with hook-delivered status/read/stop events.

Required Shape

  1. Add Cline as a PTY tool with a bespoke or Claude-like ToolConfig, not OpenCode's plugin config (src/delivery.rs:336).
  2. At launch, pass --hooks-dir $HCOM_DIR/cline-hooks and install hcom-owned wrappers there.
  3. Replace sed/awk hook scripts with minimal wrappers that exec a Rust parser, e.g. hcom hook-relay <event>.
  4. Include the full hook set (or explain the subset), in particular PostToolUse for in-turn pickup.
  5. Inject initial prompts using Cline's actual CLI grammar (positional or cline task <prompt>), not --prompt.
  6. Mark resume/fork unsupported until a ResumeSpec with Cline task-id semantics exists.
  7. Restore run_pty_test_opencode to the test entry list and add Cline coverage separately.
  8. Add cline to RELEASED_TOOLS (or remove it from the surfaces that already treat it as released).
  9. Update the bootstrap DELIVERY_AUTO branch to match the chosen delivery model.

Merge Recommendation

Reject. Rebuild around PTY plus runtime-injected hooks. The likely implementation is smaller and cleaner than the current forked scaffolding.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants