@picgo/dsh-plugin

dsh plugin --profile web add @picgo/dsh-plugin

@picgo/dsh-plugin

Upload images and files to your image host from DeepSeek Harness, powered by PicGo.

Harness can show your agent a screenshot, but it has no way to turn a local file into a link. So when the agent writes a README, renders a chart, or captures a screenshot, the image stays on disk and ![](./out.png) becomes a dead link the moment you push. This plugin closes that gap.

It uploads through whatever image host you already configured in PicGo — PicGo Cloud, GitHub, S3, Tencent COS, Qiniu, or any third-party uploader plugin you installed. Nothing to re-configure. If you've never used PicGo, it walks you into PicGo Cloud's free tier.

If the PicGo desktop app is running, uploads go through it, reusing the image host you set up in its window. Otherwise they run in-process. See [Upload routes](#upload-routes).

Install

dsh plugin --profile web add @picgo/dsh-plugin

Then boot as usual:

dsh --profile web

What you get

picgo_upload — a tool the model calls on its own when a local file needs to become a link. Returns structured results, so in Code Mode you can use it directly:

const { uploaded } = await tools.picgo_upload({ paths: ['/tmp/chart.png'] })
console.log(uploaded[0].imgUrl)

/picgo — a command that uploads without spending a model turn:

Command · What it does

/picgo · Upload the clipboard image

/picgo <path>... · Upload one or more files

/picgo status · Show the active host and sign-in state

/picgo login [token] · Sign in to PicGo Cloud

/picgo logout · Sign out

A bundled skill that teaches the model when to upload — inserting a screenshot into docs is the primary case — and when not to (you named a specific destination, you want a local copy).

Upload routes

There are two ways this plugin can reach your image host, and it picks one per upload:

1. The PicGo desktop app, when it is running. It exposes a local upload server, and using it means your uploads honour the host you configured in the app's window.

2. In-process PicGo, otherwise — the picgo library reading ~/.picgo/config.json.

This matters because the two read different config files. The desktop app stores its settings in the system application-data directory (on macOS ~/Library/Application Support/picgo/data.json), while the library reads ~/.picgo/config.json. If you have only ever used the GUI, the library route sees a config you never touched — most likely empty and defaulting to PicGo Cloud. Preferring the app is what makes "it just uses my existing setup" true.

Upgrading from 0.1.x? If the desktop app is running and the two configs point at different hosts, your uploads will now land on the app's host rather than the CLI's. Set gui.mode: off to keep the old behaviour.

/picgo status tells you which route is active. Two things worth knowing about the desktop-app route:

• The app copies each URL to your clipboard and shows a notification — that is the app's own behaviour and this plugin cannot turn it off.
• If an upload there fails with a login error, sign in from the app's own window. /picgo login writes the PicGo CLI config, which the desktop app does not read.

First run

If you've never configured PicGo, uploads default to PicGo Cloud, which needs a one-time sign-in. The free tier covers casual use.

/picgo login

That opens your browser and reports back when it completes. If you already have a token from the PicGo Cloud dashboard, /picgo login <token> is instant.

The model will never run this for you: with no token the sign-in blocks waiting on a browser callback, which would hang the session. It relays the instruction and waits.

Already using GitHub, S3, or another host in PicGo? None of this applies — your existing config is used as-is and no sign-in is involved.

Configuration

Every field has a working default. Override them from your profile's cordis.patch.yml:

- id: picgo
  name: '@picgo/dsh-plugin'
  config:
    silent: true
    timeoutMs: 120000

Field · Default · Meaning

configPath · '' · PicGo config file; empty uses PicGo's own default (~/.picgo/config.json)

silent · true · Suppress PicGo's console output and its picgo.log writes

timeoutMs · 120000 · How long to wait for one upload

registerSkill · true · Register the bundled picgo-upload skill

registerCommand · true · Register the /picgo command

announceSignIn · true · On startup, point a signed-out PicGo Cloud user at /picgo login

gui · see below · How to reach a running PicGo desktop app

gui controls the desktop-app route described in [Upload routes](#upload-routes):

Field · Default · Meaning

gui.mode · auto · auto uses the app when it answers; off never tries; only requires it rather than uploading to a different host

gui.host · 127.0.0.1 · Where the app's upload server listens

gui.port · 36677 · "

gui.secret · '' · Auth secret, if you enabled one in the app. Empty falls back to $PICGO_SERVER_SECRET

gui.probeTimeoutMs · 1500 · How long to wait for the app to answer a heartbeat

gui.probeTtlMs · 5000 · How long a heartbeat result is reused, so a multi-file upload does not re-probe per file

gui.timeoutMs · 0 · Upload deadline for this route; 0 inherits timeoutMs

A patch replaces a row's entire config rather than merging keys, so restate every field you want to keep. Within gui, unset keys still fall back to the defaults above — overriding gui.mode alone

…(truncated)