DingTalk Workspace CLI (dws): a Go CLI that puts DingTalk behind one binary, for people and agents
Project brief: DingTalk Workspace is an officially open-sourced cross-platform CLI tool from DingTalk. It unifies DingTalk s full suite of product capabilities into a single package, is designed for both human users and AI agent scenarios.
At a glance
- What is it?
- dws wraps DingTalk's product APIs in a single cross-platform command line tool with JSON output, dry-run previews and installable Agent Skills. It is officially open sourced, needs enterprise admin authorization, and is still shipping betas.
- Who is it for?
- Adopt dws if your organization already runs DingTalk and you want scriptable, auditable access to calendar, chat or AITable from a shell or an agent, and you have an admin who can authorize the app. Do not adopt it if you need a stable, frozen interface today: the newest releases are betas, the README says upgrades need v1.0.7 or later, and the project is in a co-creation phase where enterprise admin authorization is a precondition, not an option.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap dws fills: DingTalk APIs without a per-product SDK
DingTalk exposes its capabilities through separate product surfaces. A script that touches calendar, chat and AITable normally means three integrations, three credential stories and three output shapes. dws collapses that into one binary named dws, installed once, with subcommands grouped by product (`dws aitable ...`, `dws calendar ...`). The README frames the audience in three lines: humans get `--help`, `--dry-run` and `-f table/json/raw`; AI agents get structured JSON responses plus built-in Agent Skills; enterprise admins get what the project calls a zero-trust architecture built on OAuth device-flow auth, domain allowlisting and least-privilege scoping.
The agent angle is the part that differs from a conventional vendor CLI. The installer ships skills in two layouts, multi and mono, and the README is explicit that CLI commands are identical in both: only the agent-side skill layout changes. That separation matters, because it means the same command surface can back a human in a terminal and a model-driven caller without forking the interface. If you only ever type commands by hand, the skill layout is irrelevant to you, and the default multi mode costs you nothing but a few extra directories.
How dws is put together: Cobra commands, embedded endpoint data, keyring credentials
The module is `github.com/DingTalk-Real-AI/dingtalk-workspace-cli`, written in Go and declaring `go 1.25.9`. The command layer is Cobra (`github.com/spf13/cobra`), and the interactive parts lean on Charm's stack (bubbletea, huh, lipgloss, bubbles), which is why the installer can prompt you to choose a skill mode on a TTY. Credential storage goes through `github.com/zalando/go-keyring`, so tokens are meant to live in the OS keychain rather than a plaintext file. Output filtering uses `github.com/itchyny/gojq`, which is the plausible mechanism behind the `-f` format selection and any structured querying of responses.
Two details in the repository layout are worth noting. First, static endpoint data is generated from what the README calls the Wukong baseline and committed under `internal/syncdata`, so a source build does not need a sibling data checkout. Second, `go.mod` contains two `replace` directives pointing at local directories: `gitlab.alibaba-inc.com/aes/aem-go-sdk => ./third_party/aem-go-sdk` and `safechat-go-sdk => ./third_party/safechat-go-sdk`. Those are vendored copies of internal Alibaba SDKs. The practical consequence is that a fresh clone builds against the checked-in third_party code, and the Makefile reflects this with `make check-safechat` and `make test-safechat`, which the help text says need CGO.
A third structural point is the authentication model. The README describes OAuth device-flow auth, which is the flow designed for input-constrained clients: the user gets a code, approves it elsewhere, and the CLI polls. Combined with `DWS_TRUSTED_DOMAINS` (example value `*.dingtalk.com`) and `DWS_ALLOW_HTTP_ENDPOINTS` defaulting to 0, the design assumes a locked-down network posture by default. Turning on HTTP endpoints is an explicit opt-in, and the default is off. That is a sensible default for an enterprise tool, but it also means a misconfigured proxy or a non-HTTPS internal endpoint will fail until you change that variable deliberately.
Installing dws and running a first command
The README gives a one-line installer for macOS and Linux. It downloads the script and pipes it to sh, and the README notes that this non-interactive path installs the multi skill layout by default.
curl -fsSL https://raw.githubusercontent.com/DingTalk-Real-AI/dingtalk-workspace-cli/main/scripts/install.sh | shOn Windows the equivalent is a PowerShell one-liner:
irm https://raw.githubusercontent.com/DingTalk-Real-AI/dingtalk-workspace-cli/main/scripts/install.ps1 | iexIf you prefer a package manager, npm works, and Homebrew needs an explicit tap URL because the Formula lives in this repository rather than a central tap.
npm install -g dingtalk-workspace-cli
brew tap DingTalk-Real-AI/dingtalk-workspace-cli https://github.com/DingTalk-Real-AI/dingtalk-workspace-cli.git
brew install dingtalk-workspace-cliFor mainland China the README lists mirror paths that avoid GitHub network issues, including setting `DWS_GITEE_REPO` so the installer resolves versions and release assets from the Gitee API, and an npmmirror registry for the npm package.
DWS_GITEE_REPO=DingTalk-Real-AI/dingtalk-workspace-cli curl -fsSL https://gitee.com/DingTalk-Real-AI/dingtalk-workspace-cli/raw/main/scripts/install.sh | sh
npm install -g dingtalk-workspace-cli --registry=https://registry.npmmirror.comBuilding from source needs Go 1.25 or later and produces the binary in the current directory:
git clone https://github.com/DingTalk-Real-AI/dingtalk-workspace-cli.git
cd dingtalk-workspace-cli
go build -o dws ./cmd
cp dws ~/.local/bin/Configuration is environment driven. The repository ships `.env.example`, which documents `DWS_CLIENT_ID` and `DWS_CLIENT_SECRET` as the required app credentials, `DWS_CONFIG_DIR` defaulting to `~/.dws`, `DWS_TRUSTED_DOMAINS` with a `*.dingtalk.com` example, and `DWS_ALLOW_HTTP_ENDPOINTS` defaulting to 0. The README's important callout is the precondition: the project accesses DingTalk enterprise data and requires enterprise admin authorization, and it points to a co-creation group for support. So the first real use is not a command, it is getting an app registered and authorized. After that, the documented self-upgrade path is `dws upgrade`, with `dws upgrade --check` to look for new versions without installing and `dws upgrade --list` to list stable releases. macOS users who hit the Gatekeeper warning are told to clear the quarantine attribute with `xattr -d com.apple.quarantine /path/to/dws`.
Where dws gets in the way: authorization, beta channel and thin documentation
The largest constraint is not technical. Enterprise admin authorization is mandatory, and the README states plainly that this is a co-creation phase project. That means an individual developer cannot simply install dws and start reading company data; someone with admin rights has to approve the app first. If your organization has no path to that approval, dws is the wrong tool regardless of how good the CLI is.
The release channel is the second constraint. The most recent tagged releases are `v1.0.61-beta.2` and `v1.0.61-beta.1`, with `v1.0.60` as the last stable tag. The README also notes that built-in upgrade requires v1.0.7 or later and that earlier versions must re-run the install script. If you pin to stable, you are behind the beta line; if you track beta, you are running pre-release code against enterprise data. That is a real decision, not a formality.
Third, the documentation is uneven in places that matter for operations. The README documents `dws upgrade`, `dws upgrade --check` and `dws upgrade --list`, and mentions SHA256 integrity verification plus automatic backup, but it does not document rollback to a previous version. For a tool that writes to enterprise systems, the absence of a documented rollback path is the kind of gap you want to settle before, not after, an upgrade. The reference material lives in `docs/reference.md` and `CHANGELOG.md`, so the README is a starting point rather than the full contract.
A fourth issue is the skill mode switch. `dws skill setup --mode mono` and `dws skill setup --mode multi` change what lands on disk, and the README says you should review the listed paths and confirm interactively. On a fleet, that interactive confirmation is an obstacle to automation, and there is no documented non-interactive equivalent for switching modes after install. Plan for the mode at install time via `DWS_SKILL_MODE`, or accept that switching later is a hands-on operation.
Alternatives: vendor CLIs, generic HTTP clients and the Feishu comparison
The closest comparison people search for is Feishu CLI. The difference is not quality, it is scope: a Feishu CLI targets Feishu's APIs, and dws targets DingTalk's. If your company runs DingTalk, a Feishu tool does nothing for you, and vice versa. The relevant question is which platform your enterprise data actually lives on.
The other real alternative is not a CLI at all: calling the DingTalk HTTP APIs directly from your own script or service. That approach gives you full control over retries, batching and error handling, and it does not add a binary to your fleet. What you give up is the parts dws already assembled: OAuth device-flow handling, keyring-backed credential storage, domain allowlisting through `DWS_TRUSTED_DOMAINS`, `--dry-run` previews and a consistent `-f table/json/raw` output contract. For a one-off integration, hand-rolled HTTP calls are often less work. For a team that needs several DingTalk products behind one interface, and especially for agent callers that need predictable JSON, the wrapper earns its place.
A third option is a generic MCP or connector layer that brokers multiple SaaS products. dws does carry agent integration metadata (`DWS_AGENT_PRODUCT`, `DWS_AGENT_HOST`, `DWS_AGENT_VER`, `DWS_AGENT_EXT` in `.env.example`), but the README describes those as metadata for ordinary non-plugin MCP requests, and it warns that `DWS_AGENT_EXT` is sensitive caller-declared JSON capped at 8 KiB and must not be treated as authentication. That is a narrower agent story than a general connector platform, and it is worth reading as such. If your goal is broad multi-vendor orchestration, dws is one vendor's surface, not a hub.
Maintenance, licence and what an upgrade actually costs
The repository is not archived. Its last push was on 2026-08-28, and the latest release, `v1.0.61-beta.2`, carries the same timestamp, so the beta line is where current work lands. That is recent activity, but the stable tag `v1.0.60` is dated 2026-08-27, one day earlier, which tells you the stable and beta channels are close together right now.
The licence is Apache-2.0, and the repository carries a NOTICE file alongside LICENSE. Apache-2.0 permits commercial use and modification and includes a patent grant, and the NOTICE file is the mechanism by which attribution obligations travel with redistributions. If you vendor dws into an internal distribution, read the NOTICE contents rather than assuming the LICENSE file is the whole story. This is not legal advice; it is a pointer to which files to read.
Upgrade cost is mostly operational. Self-upgrade pulls from GitHub Releases with SHA256 verification and an automatic backup, which the README documents. The China mirror path exists precisely because GitHub reachability is unreliable for some users, and `DWS_GITEE_REPO` changes where both the installer and the skills package resolve from. If your fleet sits behind a proxy, decide up front whether upgrades go through GitHub or the Gitee mirror, because mixing the two across machines is how you end up with divergent versions and no clear source of truth. There is no documented rollback command, so the automatic backup is the recovery path the project describes.
The dependency story also carries maintenance weight. The two `replace` directives in `go.mod` point at `./third_party/aem-go-sdk` and `./third_party/safechat-go-sdk`, so those SDKs move with the repository rather than with upstream releases. That makes builds reproducible but means security fixes to those components arrive only when the repository updates them. Check `CHANGELOG.md` before each upgrade to see whether the vendored SDKs changed.
Editorial conclusion
Adopt dws if your organization already runs DingTalk and you want scriptable, auditable access to calendar, chat or AITable from a shell or an agent, and you have an admin who can authorize the app. Do not adopt it if you need a stable, frozen interface today: the newest releases are betas, the README says upgrades need v1.0.7 or later, and the project is in a co-creation phase where enterprise admin authorization is a precondition, not an option. Before rollout, run dws upgrade --check on one machine to see which channel it resolves, and confirm whether you want the default multi skill layout or DWS_SKILL_MODE=mono.
Frequently asked questions
Can I use DingTalk on my phone?
The repository describes dws as a cross-platform CLI tool for macOS, Linux and Windows, so the documented surfaces are desktop and server shells rather than a phone app. No mobile client for dws is documented.
How do I install the DingTalk Workspace CLI (dws)?
The README gives a one-line installer for macOS and Linux, a PowerShell equivalent for Windows, plus npm, Homebrew and source builds. The non-interactive installer path installs the multi skill layout by default.
Does dws require enterprise admin authorization?
Yes. The README's important callout states that the project accesses DingTalk enterprise data and requires enterprise admin authorization, and it points to a co-creation group for support and updates.
What is the difference between the mono and multi skill modes in dws?
Multi installs per-product skills such as dingtalk-aitable and dingtalk-calendar, while mono installs one dws skill covering all products. The README states that CLI commands are identical in both modes and only the agent-side skill layout differs.
Community notes