Decisions

Why lnk-deepseek runs DeepSeek Harness the way it does. Link's own decisions about harnesses are on its Agents Decisions page.

Through a bridge of its adapter's. dsh speaks no chat channel and serves no chat completions, so lnk-deepseek serve is its endpoint, the way Link Harness is its own: Link carries the channels to it. Behind it runs one dsh --profile acp, the Agent Client Protocol over stdio, because that profile keeps many sessions in one process and takes one up again after a restart, where its headless profile starts a process per message and its SDK profile can't resume. Each chat is a session, named in threads.json.

Why are DeepSeek Harness's own sandbox and approvals off?

Because Link's sandbox confines it, and nobody is there to approve. Its own sandbox is bubblewrap or Landlock on Linux and Seatbelt on a Mac, which can't nest inside Link's; where it can't start, dsh refuses to run a command at all. Its approvals would wait on a person who reads the chat, not a prompt. Link's sandbox gives it the same bounds: its home and the files folder, and the network through Link's proxy.

Because you didn't ask for it. By default dsh attaches the session's log and its list of plugins to each request on DeepSeek's route, even to another address, and keeps its telemetry and web search on DeepSeek's servers. Link reaches the model through your own provider, so none of those rows is needed. Its web search is off with them, since it needs a DeepSeek key.

lnk-deepseek serve answers chat completions on port 18820 and runs one dsh --profile acp behind it, started again if it stops. A thread's turns run one at a time, and a turn dsh says nothing of for 30 minutes is cancelled, so the next can run. dsh starts on its own, whoever asked for it, and has 2 minutes to answer ACP's initialize. Starting or taking up a thread's session has 2 minutes too, then the message fails and the next one tries again.

GET 127.0.0.1:18820/health answers once dsh does, waiting up to 3 seconds for one that is starting. GET 127.0.0.1:18820/_link/proof is where it proves to Link's channels that it holds the endpoint's key before they send it.