Skip to content
中文
☰
Tutorial / Step 8

Installing Third-Party Plugins Safely

Four checks — source, permissions, versioning, and rollback — to reduce the risk of adding third-party code to the Agent Runtime.

Answer in brief

Before installing a third-party Plugin, verify its repository and maintainer, inspect requested permissions and executable hooks, pin a reviewed version, and prepare a rollback path. Directory verification is only a source signal; it is not proof that a Plugin is safe for your environment.

A Plugin is not a passive document. It may enter the Cordis runtime, read your workspace, register tools, connect to the network, or modify the interface — so evaluate it as a third-party code dependency before installing.

1. Verify the Source

  • Are the package name, repository name, and author consistent?
  • Does the npm page link back to the same repository?
  • Does the repository have a license, release history, and recent maintenance?
  • Does the install command come from the repository README, rather than comments or screenshots?

This site’s “source Verified” status only reflects what third-party directories report; it is not equivalent to a security audit by this site.

2. Identify the Permission Surface

Focus on whether the Plugin accesses:

  • The file system;
  • Shell or child processes;
  • Browser and desktop input;
  • The network and external APIs;
  • API Keys, SSH Keys, or database credentials;
  • The Session Log and model context.

The more powerful the feature, the broader the permissions tend to be. Confirm that each permission genuinely serves your goal.

3. Pin the Version

Things change fast during the Developer Preview. After a successful evaluation, record the specific version or commit rather than following uncontrolled latest code forever. Re-check permissions and changelogs when upgrading.

4. Prepare for Rollback

Save your configuration and workspace state before installing. Start in a non-sensitive test repository and complete the following checks:

  1. The Harness starts and exits normally.
  2. The Plugin only registers the expected capabilities.
  3. No unexpected network requests occur.
  4. The base Profile recovers after uninstalling.

5. Minimize Exposure

Use low-privilege accounts, temporary credentials, containers, or sandboxes. When databases and remote servers are involved, prefer read-only accounts and host allowlists.

You can view the permission labels and source information curated by this site in the Plugin Hub, but ultimately you should still read the original repository.

Inspect More Than src

Review package lifecycle scripts, dependency provenance, default network or telemetry behavior, credential logging, and whether unload cleans registrations, listeners, and background processes.

Isolated Trial

  1. Create a secret-free workspace.
  2. Use temporary, low-quota credentials.
  3. Export the current profile.
  4. Pin one Plugin version and enable only that increment.
  5. Observe runtime and network changes.
  6. Test valid, empty, and invalid input.
  7. Uninstall and verify recovery.

Proceed only when provenance is clear, permissions match the purpose, and rollback works. Popularity and “verified source” status are not substitutes for a security review.

Primary sources