A launcher for local coding-agent clients like Pi, Opencode, Copilot

[Chida82]

ds4-launch is a small C launcher for local coding-agent clients that should
talk to ds4-server. It supports:

• ds4-launch pi
• ds4-launch copilot
• ds4-launch opencode
• ds4-launch open-code
• ds4-launch open_code

top point:

• Adds ./ds4-launch as a convenience entry point for Pi, Copilot CLI, and
  OpenCode against local ds4-server.
• Reuses an existing DS4 server by lock-owner pid and lsof listener discovery
  instead of failing on the single-instance guard.
• Keeps server customization as ordinary ds4-server flags passed after the
  tool name.
• Adds ./ds4_test --launch for launcher parser and pid/port extraction logic.

User Behavior

Arguments after the tool name are treated as ds4-server startup options.

./ds4-launch pi --ctx 100000 --kv-disk-dir /tmp/ds4-kv --kv-disk-space-mb 8192
./ds4-launch copilot --port 9000
./ds4-launch opencode

The launcher parses only the options it needs for client configuration:

• --host
• --port
• -c / --ctx
• -n / --tokens

Known value-taking server options are skipped so later options are read
correctly. Unknown options are left delegated to ds4-server by not trying to
interpret them in the launcher.

If no DS4 process is running, ds4-launch starts ds4-server in a detached
background session, writes server stdout/stderr to /tmp/ds4-launch-server-*.log,
waits for the TCP port to become reachable, then execs the selected client.
After exec, the terminal belongs to the client tool.

If a DS4 process is already running, the engine lock prevents a second server
from starting. The launcher handles this before or after a failed startup by:

1. Reading the owner pid from the DS4 lock file.
2. Confirming the process still exists.
3. Running lsof -Pan -p PID -iTCP -sTCP:LISTEN.
4. Extracting the listening port from the TCP listener line.
5. Printing the discovered pid and port before launching the client.

This keeps accidental second model loads from happening while still making the
common workflow pleasant: start or reuse the local server, then hand over the
terminal to the requested tool.

Client Wiring

All clients use the display/model string:

DeepSeek V4 Flash (ds4.c local)

Code Shape

The file follows the style of the rest of the C binaries in the repository:

• single-purpose standalone C file;
• narrow static helpers;
• explicit argument parsing;
• simple stderr diagnostics;
• no new runtime dependencies beyond POSIX APIs and the existing use of
  system tools on macOS (lsof for pid-to-port discovery).

The unit tests are embedded in ds4_launch.c behind DS4_LAUNCH_TEST, but the
normal binary compiles without the test entry point. The test object is linked
into ds4_test, which exposes the narrow check as:

./ds4_test --launch

Test Coverage

The launch test group covers:

• supported and rejected tool names;
• parsing server options needed for client configuration;
• skipping known value-taking pass-through options;
• leaving unknown options delegated;
• parsing the pid from the DS4 lock error text;
• parsing TCP listening ports from representative lsof output.

These tests avoid starting a real ds4-server, loading a GGUF, or executing any
agent client. That keeps them fast and appropriate for the normal C unit-test
runner.

[antirez]

Nice idea in principle, but let's think about it, maybe ./ds4 --agent pi, but I'm starting to consider the idea of having also a C coded minimal and functional coding agent with Chrome integration for searches that is also part of the project.

[Chida82]

The goal is to simplify usage and configuration by leveraging some existing agents. I initially tried with Claude, but it didn’t work well, while these three—especially PI—perform adequately.
Having a lightweight, vertical, and highly optimized agent with minimal dependencies would also be an excellent solution. I would be the first to use it—possibly just as a set of skills and a CLI that can be packaged and distributed with those skills.
Feel free to make your own assessments—deploy it temporarily if needed—or suggest any changes you think are appropriate. I’d be happy to implement them.

[Chida82]

Nice idea in principle, but let's think about it, maybe ./ds4 --agent pi, but I'm starting to consider the idea of having also a C coded minimal and functional coding agent with Chrome integration for searches that is also part of the project.

I have the feeling that, for agent, you are taking inspiration from pi-agent.

Over time, the agent might develop additional needs, such as having a to-do capability. I think we should allow at least some room for expansion.

That expansion could happen by writing additional code, or maybe through CLI-based extensions. For example, how could a To-do CLI interact with the main agent?

What do @antirez think about putting more emphasis on CLIs rather than MCP-based systems?