UI-TARS Desktop is part of a multimodal AI agent stack that uses vision and graphical interfaces to operate computers and web browsers. Its desktop application provides local and remote computer and browser operators, while the related Agent TARS project offers terminal and web interfaces for multimodal agents. Catalogue entries connect agent workflows and MCP tools to this stack.
Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add commands/bytedance/ui-tars-desktop/todogit clone --depth 1 https://github.com/bytedance/UI-TARS-desktopWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/commands/bytedance/ui-tars-desktop/todo)<a href="https://agentmods.dev/commands/bytedance/ui-tars-desktop/todo"><img src="https://agentmods.dev/badge/commands/bytedance/ui-tars-desktop/todo.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00000 | $0.00542 |
| Opus 5 | $0.00000 | $0.00271 |
| Sonnet 5 | $0.00000 | $0.00108 |
| Haiku 4.5 | $0.00000 | $0.00054 |
Grade A, and why
TODO scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 6d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
What it actually says
TODOs
- Every time Claude runs a python script,
pythonis used as the interpreter. Which fails every time.- Thankfully, Claude retries with
python3and uses that for the rest of the chat.- Hence the idea to have some memory concept across chats! Very selective memory and very minimal.
- I was thinking of adding a tool for this server alone, one to write to and another to read from this cmdline memory... and then otherwise instruct Claude to judiciously use the memory (i.e. never if possible)
- And, don't put any constraints on the memory other than a list of strings. Claude can do all that on his own (i.e. a line with
pythoh3alone should be sufficient, in fact I could do some testing with that alone and see how Claude does)
- Another example would be
unameon a Windows machine. - These different scenarios aren't necessarily mission critical to fix but they offer an opportunity to improve the experience.
- The solution may not be generalizable too and might be specific to command that fails, i.e. if I pass the OS name in the ListTools response, that will likely fix that issue.
- i.e. routinely
pythonis used and thenpython3 - Or, should I have some static mappings of common commands that fail and when they do, use the fallback? And find a way to tell the LLM? Or,
- Or would some sort of command lookup mechanism be useful? i.e. python3 instead of python
- Thankfully, Claude retries with
- Add windows tests, linux tests and macOS tests for nuances of each. i.e. pwsh, pwsh-core, cmd.exe on Windows.
- Add a server side request to score risk of a tool request (specific to run_command/run_script?) - this wouldn't be a tool the LLM uses, but rather the client.
- Claude makes tool request, client passes it to server for scoring, server returns risk, client decides to prompt (or not) and then client sends tool request to server...
- Or, have client use another LLM score it?
- I chimed in about this on this discussion: https://github.com/orgs/modelcontextprotocol/discussions/69
- Also, some tools might be able to be marked safe in their spec, i.e. getting date/time, fetching a web page... inherently mostly "safe"
- The fewer prompts the user sees, the most likely that the user will actually read the requested tool use. Otherwise, next next next prompt fatigue kicks in regardless of risk
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 6d ago First seen · 21 lines · 0 tokens per session scan A f3e3db15ade6
TODO is a command published in the GitHub repository bytedance/UI-TARS-desktop (38,865 stars, last pushed 1mo ago), licensed Apache-2.0. It costs nothing until one of its globs matches a file; then it loads 542 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other commands, from other repositories
chunkhound-release-notes
Generate release notes for a ChunkHound production release.
review-pr
Review Github Pull Request.
/release
Release a new version — updates CHANGELOG, pyproject.toml, creates git tag, and pushes.
test_mcp
Test all rust-docs-testing tools found in @rust-docs-mcp/src/service.rs.
update_mcp_tools_list
Read the rust-docs-mcp/src/service.rs module and ensure that the README.md and the rust-docs-mcp/install.sh files have up to date lists of the tools available in the MCP.
axstream-teach
Compile a UI task into a fast replayable macro (do it once, instant forever).