The DingTalk OpenClaw connector, and the risk notice its vendor put at the top
Official OpenClaw DingTalk channel plugin | 钉钉官方 OpenClaw 插件
At a glance
- What is it?
- This is DingTalk's own channel plugin for OpenClaw, giving an agent access to messages, documents, to-dos, AI tables, calendars and DING reminders, installed with an npx command and a QR code scanned in the DingTalk app. What makes it worth reading carefully is the security section: the vendor states plainly that the agent acts as your user identity, that prompt injection is an inherent risk, and that it should not be deployed in enterprise production.
- Who is it for?
- Adopt the connector if you want a personal assistant reachable from DingTalk and you are willing to reason about what an agent holding your user identity can be talked into doing, because the plugin's own documentation tells you not to deploy it in enterprise production and not to loosen its default access controls. Do not install it on a host older than OpenClaw 2026.8.1 alongside plugin 0.8.26, since the README routes older hosts to 0.8.25.
- Can I use it commercially?
- Yes. MIT 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 27 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 20, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Seven capability groups, one chat channel
The connector is the official DingTalk channel plugin for OpenClaw, published to npm as `@dingtalk-real-ai/dingtalk-connector`, and its purpose is to give an OpenClaw agent a way to receive and send DingTalk messages while acting on the surrounding workplace services.
The capability list is broad enough to be worth breaking down, because it determines what an agent can do once it is connected. Documents can be created, appended to, searched and listed. DING messages, which are DingTalk's strong reminder, can be sent to a user or a group. Messages can be received from group chats and direct chats, answered automatically, and sent as text or Markdown, including mentions of specific members. Personal to-dos can be created, queried and given deadlines. AI tables can be created with rows read, written and conditionally queried. Calendar management covers events with full create, query, modify, delete and search, participant management, and free and busy queries. And there is a log capability for submitting daily or weekly reports and querying their history.
Two items are marked as still in development: group to-dos, as distinct from the personal ones that work today, and uploading and downloading files to DingTalk's cloud drive. That distinction matters if you are planning a workflow around it, and it is the kind of thing a capability table usually hides.
The rest of the feature list is about how an agent behaves inside a chat rather than what it can reach. Replies stream into a message card with a typewriter effect instead of appearing all at once. Interactive cards show live status, distinguishing thinking, generating and complete, and carry confirmation buttons for sensitive operations. Rich media handling accepts image, audio and file attachments and uploads local images automatically. Session management keeps multi-turn context while isolating direct and group conversations from each other.
Taken together, this is a much larger surface than a messaging bridge. It is closer to giving an agent an authenticated API client for a workplace suite, and that framing is the right one to hold while reading the rest of the documentation.
The security section is the most useful paragraph in the README
The README contains a section headed as a security and risk notice to be read before use, and it is unusually direct for a vendor document. It deserves to be summarised rather than paraphrased loosely.
The stated position is that connecting to OpenClaw's AI automation capabilities carries inherent risks, and the README names three of them explicitly: model hallucination, uncontrolled execution, and prompt injection. It then says the thing that matters most, which is that once DingTalk permissions are authorised, OpenClaw will execute operations as your user identity within the authorised scope, which can lead to sensitive data leakage or operations that exceed your permissions.
That sentence is the whole security model in one line. The agent is not a restricted bot with a narrow capability list. It is you, authenticated, and it acts with your authority. Every capability in the previous section, document creation, calendar modification, to-dos, table writes, is an action taken in your name in a system that holds your employer's data. A hallucination is therefore not a wrong answer, it is a wrong write.
The README also states that the plugin enables default protections at several layers, that risk still exists, and that it strongly recommends not actively modifying any default security configuration, on the grounds that relaxing those restrictions raises the risk substantially and the consequences are yours to bear. It goes further and recommends treating the connected DingTalk bot as a personal conversation assistant, avoiding direct deployment in enterprise production environments, and following company information security rules if you use it on a company account. It closes by saying that using the plugin means you accept the risks and responsibilities.
Most projects put a security section at the bottom, in smaller type, next to a licence. This one is in the middle of the README, before installation, in bold. For an agent integration that holds a user's credentials across seven service categories, that placement is the correct one, and it is the reason this article leads with it.
A hard host compatibility boundary at 0.8.26
Before anything else, there is a version constraint that is more than a minimum version number.
The requirement is OpenClaw at 2026.8.1 or later, checked with `openclaw -v`. The README explains what that host version brings, and the explanation is not cosmetic: this plugin version uses a new plugin SDK, a runtime configuration snapshot, and host-managed message queue and interruption semantics. Those are three architectural changes, not three bug fixes.
The consequence is that hosts and plugins have to move together. The README's instruction is explicit: older hosts should continue using plugin 0.8.25 and upgrade the host before upgrading the plugin. In other words, 0.8.26 is not backward compatible with an older OpenClaw, and the upgrade path is host first, then plugin. Getting that order wrong gives you a plugin that loads against an SDK that no longer has the shape it expects.
The release history shows how that boundary was reached. Version 0.8.26-beta.0 was published on 2026-09-02 with the title OpenClaw 2 runtime compatibility, beta.1 followed later the same day, and v0.8.26 with the title OpenClaw 2 GA compatibility on 2026-09-03, the same timestamp as the last push to the repository. So a runtime compatibility change went from first beta to general availability in about a day, and the previous stable line was 0.8.25.
A one-day beta cycle is fast, and for a plugin whose entire job is shuttling messages and credentials it is also reasonable, since the surface area is narrow. The thing to watch is the numbering convention. The 0.x line means there is no compatibility promise, and a 0.8.27 could carry the same class of breaking change that 0.8.26 did. Anyone deploying this into a working assistant should treat the plugin version as something to pin rather than track.
Installing with npx, authorising with a QR code, restarting the gateway
The recommended install is a single command, and the authorisation step happens in the terminal rather than in a browser.
npx -y @dingtalk-real-ai/dingtalk-connector install
openclaw gateway restart
npm install -g [email protected]The first command installs the plugin and then displays a DingTalk authorisation QR code in the terminal. You scan it with the DingTalk mobile app and tap the one-click create new bot option, which creates the bot and completes the authorisation. Success is reported by a line reading `Success! Bot configured.` After that you restart the Gateway with the second command, which is what makes the new channel take effect.
The failure behaviour is worth noting because it is handled well. The README says a failed scan does not affect the installation: even if the QR flow breaks, whether from a timeout or the code not displaying at all, the plugin itself still installs normally. Credentials can be configured afterwards by following the manual setup guide in `docs`. A provisioning script that hard-fails on a QR timeout would leave people with a half-installed system and no obvious next step; this one separates installation from authorisation deliberately.
The manual configuration path also matters for anyone deploying this more than once. A QR scan is bound to a person scanning it, so an automated or repeated setup has to go through the credential route, and the existence of a documented guide for that is the difference between a supported workflow and a workaround.
The remaining advanced documentation is worth knowing about by name. There is a DingTalk DEAP Agent integration guide, described as covering local device operation capability, which is the one document on that list that extends the plugin's reach beyond DingTalk's own APIs and onto the machine it runs on. There is a multi-agent routing guide covering zero-configuration setup, complete examples and a collaboration mode. And there is a troubleshooting document. The primary user guide is not in the repository at all; it is hosted on DingTalk's own document platform.
Streaming cards, status, and confirmation buttons as the safety mechanism
The most interesting design decision in this plugin is not a capability, it is how it makes an agent's uncertainty visible inside a chat client.
Three features work together for that. The AI Card streaming response renders the reply progressively in a message card with a typewriter effect, so a user watching the card sees the agent working rather than a frozen bubble. Interactive cards carry real-time status updates that distinguish thinking, generating and complete, which is a small vocabulary that does a lot of work: a user who can see that an agent is still generating will wait, and a user who sees a completed card with no answer knows something finished and went nowhere.
The third is the important one. Interactive cards provide confirmation buttons for sensitive operations. In a system where the agent acts as your user identity, the difference between an agent that can create a document and an agent that must ask before creating a document is the difference between a tool and an incident. Putting the confirmation in the card rather than in a chat message means it is rendered as a button, so the user does not have to type an approval phrase correctly.
That mechanism only works if it is actually used, which is why the next feature matters. The permission policy layer provides flexible access control strategies for both direct chats and group chats. In a group chat, an agent that can act on any message from any member is a much larger exposure than the same agent in a private conversation, because the membership of a group changes without the owner's involvement. Restricting which conversations may trigger actions, and which may trigger destructive ones, is the control that makes group deployment survivable at all.
The interaction with the security notice is the point. The README tells you not to loosen the default security configuration, and the features described here are the reason that advice is coherent: there is a layered model underneath the settings, with card-level confirmation for individual actions and a policy layer for whole conversations. Relaxing the policy layer because a particular group member keeps hitting a prompt is exactly the change the warning is about.
Session management completes the picture. Multi-turn conversation context is preserved, and direct and group sessions are isolated from each other, so a group conversation cannot read the history of your private one. For an agent that holds document and calendar access, that isolation is a privacy boundary rather than a convenience feature.
The manifest ships with lint disabled and three test scripts pointing at one file
The package manifest is worth reading closely, because it documents what the project's own quality gates are, and the answer is thinner than the feature list suggests.
"lint": "echo 'Lint check skipped'",
"test": "vitest run tests/gateway-methods.unit.test.ts",
"test:integration": "vitest run tests/gateway-methods.unit.test.ts",
"build": "tsdown"The lint script does not lint. It echoes that the check is skipped, and `lint:fix` does the same. `version:check` and `release:prepare` also do nothing but echo, and the `dev` script is a reminder to run `openclaw start` instead. So in the published manifest there is no linting, no version consistency check and no release preparation step.
Type checking is real, though: `type-check` runs `tsc --noEmit`, and TypeScript is the primary language, so a type error fails that one gate. Builds go through tsdown, and the package publishes two entry points, the main one and a `./bundled` one with its own build output, which is the usual arrangement for shipping a copy with dependencies inlined for hosts that cannot resolve them.
The test scripts are the more specific finding. `test`, `test:unit` and `test:integration` all run the same command against the same single file, `tests/gateway-methods.unit.test.ts`. Three script names, one unit test file, no integration test. The coverage script runs the full suite while excluding `tests/gateway-methods.test.ts`, a file that none of the other scripts reference, so whatever that file contains is excluded from the only command that would otherwise run everything.
None of this means the code is untested, and the repository does have a `tests/` directory, a `vitest.config.ts`, a UI mode, a watch mode and a `.env.test` alongside `.env.test.example`. But the scripts a new contributor or a CI system will actually invoke run one file, and a name like `test:integration` pointing at a file with `unit` in its name is the kind of thing that makes a coverage number look better than it is.
Two smaller packaging details round out the picture. The `files` array ships `src/` and `index.ts` alongside `dist/`, so the TypeScript source travels with the package, which is unusual and useful when you want to read what you installed. And a `secret-contract-api.ts` file at the top level of the repository names the credential surface explicitly, which is a good sign next to a plugin whose main risk is over-broad authorisation.
Multi-agent routing, and the wider DingTalk-Real-AI organisation
Multi-agent routing is listed as a supported capability, and it is the one that changes the shape of a deployment rather than extending it.
The described model is connecting multiple bots to different agents, so each one provides a specialised service. The setup guide in `docs` is described as covering configuration from zero, a complete example, and a collaboration mode, which suggests the third is the interesting one, where more than one agent participates in a conversation rather than each bot being an independent assistant.
Once you are routing messages to different agents, the permission policy layer and the session isolation become the load-bearing parts of the design rather than nice-to-haves. A routing configuration is a set of decisions about which conversations reach which agent with which authority, and the failure mode of getting one wrong is an agent with calendar access handling a group conversation it was only supposed to answer questions in.
The repository is part of a wider organisation, and the README's triage guidance maps the boundaries precisely, which is useful if you file something in the wrong place. Business capabilities of DingTalk that are outside this connector go to DingTalk's developer ticket portal. Anything about OpenClaw itself, described as the gateway, models and multi-channel, goes to the openclaw repository. Anything about dws, the DingTalk workspace CLI, goes to a separate repository in the same organisation. And only connector issues come to this repository.
That four-way split tells you the surface area. This repository is one channel adapter in a stack that includes the agent host and at least one other first-party CLI, and the boundary is drawn at the point where this plugin stops being responsible.
The contribution process is documented with the same precision, down to pointing at two reference pull requests, one for documentation changes and one for code changes, and asking for smaller diffs with clear descriptions and verification steps while larger changes open an issue first. There is also a quarterly acknowledgement programme offering small gifts or a visit to DingTalk to the three highest contributors each quarter, which is an unusual thing to find in a README and says something about how the project intends to keep its contributor pipeline open.
MIT licensing, a shipped plugin manifest, and what to read before you connect it
The licence is the MIT License, with the text in a `LICENSE` file at the repository root, and the README states the project is based on MIT. That permits commercial use, modification and redistribution with attribution and no warranty, which matters here because this is a first-party vendor plugin intended for use inside a company.
The plugin manifest, `openclaw.plugin.json`, is included in the `files` array, so the metadata OpenClaw reads at load time ships with the package. The `skills/` directory is shipped too, which means the connector distributes agent skills as well as channel code, and that is worth understanding before installation because it changes what the agent is told it can do. The `entry-bundled.ts` file and its corresponding build output exist as a second entry point, and the `docs` directory is published as `docs/*.md`, so the advanced guides travel with the package rather than only living on GitHub.
There is a bilingual README, `README.md` and `README.en.md`, which is a reasonable default for a product of this origin, and a `CHANGELOG.md` that the README links from the header and from the support section.
What to read before connecting this to anything is short and specific. Start with the security notice, because it describes the authority model accurately and it is the vendor's own assessment. Then read the manual setup guide so you know exactly which credentials are being requested and can grant a narrower set than the one-click path might ask for. Then, if you intend to run this in a group rather than a private chat, read the multi-agent routing guide and the permission policy behaviour together, because that is the configuration where a mistake is visible to other people.
The last thing worth saying is not about the software. The README recommends against enterprise production deployment and suggests treating the bot as a personal assistant. That is unusual advice from a vendor whose product is aimed at companies, and taking it at face value is the correct reading of what this plugin is: a demonstration of how much an agent can do with a workplace account, with the safety rails still being worked out.
Editorial conclusion
Adopt the connector if you want a personal assistant reachable from DingTalk and you are willing to reason about what an agent holding your user identity can be talked into doing, because the plugin's own documentation tells you not to deploy it in enterprise production and not to loosen its default access controls. Do not install it on a host older than OpenClaw 2026.8.1 alongside plugin 0.8.26, since the README routes older hosts to 0.8.25. Verify first by checking openclaw -v, reading docs/DINGTALK_MANUAL_SETUP.md before you scan the code so you know what credentials are being requested, and running npm test to see which single test file the manifest's test, test:unit and test:integration scripts actually execute.
Frequently asked questions
What is the DingTalk OpenClaw connector?
It is the official OpenClaw DingTalk channel plugin, published to npm as @dingtalk-real-ai/dingtalk-connector. It connects an OpenClaw agent to DingTalk and gives it message sending and receiving, document creation and search, DING reminders, personal to-dos, AI table reads and writes, calendar and event management with free and busy queries, and daily or weekly report logging.
What version of OpenClaw does the connector require?
OpenClaw 2026.8.1 or later, which you check with openclaw -v. The README says that host version brings a new plugin SDK, a runtime configuration snapshot and host-managed message queue and interruption semantics, so older hosts should stay on plugin 0.8.25 and upgrade the host first.
How do I install and authorise the DingTalk connector?
Run npx -y @dingtalk-real-ai/dingtalk-connector install, scan the QR code shown in the terminal with the DingTalk mobile app, tap the one-click create bot option, look for the line Success! Bot configured., and then run openclaw gateway restart. A failed QR scan does not stop the plugin installing, and credentials can be configured later using the manual setup guide in docs.
What risks does the DingTalk connector README warn about?
It names model hallucination, uncontrolled execution and prompt injection as inherent risks, and states that once authorised OpenClaw acts as your user identity within the granted scope, which can cause sensitive data leakage or operations beyond your permissions. It recommends treating the bot as a personal assistant, avoiding enterprise production deployment, and not modifying the default security configuration.
Does the connector project run lint and integration tests?
The published manifest's lint and lint:fix scripts only echo that the check is skipped, as do version:check and release:prepare. The test, test:unit and test:integration scripts all run the same single file, tests/gateway-methods.unit.test.ts, while test:all runs the full suite and the coverage script excludes tests/gateway-methods.test.ts.
Can I connect different DingTalk bots to different agents?
Yes. Multi-agent routing is a listed capability for connecting multiple bots to different agents, with a setup guide in docs covering configuration from zero, a complete example and a collaboration mode. The plugin also has a permission policy layer for direct and group chats, and session isolation so a group conversation cannot read a private one's history.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/dingtalk-real-ai-dingtalk-openclaw-connector)