Skip to content

feat(comparisons): add code-sandbox and session-policy rows #6517

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
waleedlatif1 merged 2 commits into from
Aug 11, 2026
Merged

feat(comparisons): add code-sandbox and session-policy rows #6517

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
24848f4
feat(comparisons): add code-sandbox and session-policy rows
waleedlatif1 Aug 11, 2026
a3a39f4
fix(comparisons): resolve customCodeSteps contradictions for Retool a…
waleedlatif1 Aug 11, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions apps/sim/app/(landing)/comparisons/comparison-sections.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -95,6 +95,7 @@ export const COMPARISON_SECTIONS: ComparisonSectionDef[] = [
{ key: 'modelAndToolGovernance', label: 'Model & tool governance' },
{ key: 'credentialGovernance', label: 'Credential governance' },
{ key: 'sso', label: 'Single sign-on (SSO)' },
{ key: 'sessionPolicy', label: 'Custom session policy' },
{ key: 'thirdPartyVetting', label: 'Vetted first-party integrations' },
{ key: 'piiRedaction', label: 'PII redaction' },
{ key: 'dataRetention', label: 'Custom data retention' },
Expand Down Expand Up @@ -129,6 +130,7 @@ export const COMPARISON_SECTIONS: ComparisonSectionDef[] = [
{ key: 'integrationCount', label: 'Integrations' },
{ key: 'triggerTypes', label: 'Trigger types' },
{ key: 'customCodeSteps', label: 'Custom code steps' },
{ key: 'codeSandboxRuntime', label: 'Configurable code sandboxes' },
{ key: 'apiPublishing', label: 'API publishing' },
{ key: 'extensibilitySdk', label: 'SDKs & extensibility' },
{ key: 'mcpPublishing', label: 'Publish as MCP server' },
Expand Down
40 changes: 40 additions & 0 deletions apps/sim/lib/compare/data/competitors/claude-cowork.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -645,6 +645,31 @@ export const claudeCoworkProfile: CompetitorProfile = {
},
],
},
codeSandboxRuntime: {
value:
'Partial: shell commands and any code Claude writes run in an isolated sandbox (a dedicated Linux VM for local sessions, a per-session temporary sandbox on Anthropic-managed infrastructure for cloud sessions), and within a session Claude can itself install dependencies at run time from approved package managers (npm/registry.npmjs.org, PyPI/files.pythonhosted.org, GitHub, crates.io, Yarn). What an administrator configures is the org-wide network-egress policy rather than the environment: Team and Enterprise organization owners choose, in Organization settings > Capabilities, between network access off (Claude "operates with pre-installed packages only"), package managers only, package managers plus an admin-specified domain allowlist, or all domains except Anthropic\'s legal blocklist.',
detail:
'The configuration surface is an org-wide network-egress policy plus run-time installs the agent performs itself, not a declared environment: there is no manifest of packages, no OS/system-package list, no preinstalled-CLI selection, and no custom base image or Dockerfile for the sandbox, and Anthropic does not publish the preinstalled package set for Cowork sandboxes. Network settings apply when a session is created, so changing them mid-conversation requires starting a new one.',
shortValue: 'Partial: agent installs packages at run time; environment not declarable',
confidence: 'verified',
sources: [
{
url: 'https://support.claude.com/en/articles/14479288-claude-cowork-architecture-overview',
label: 'Claude Cowork architecture overview',
asOf: '2026-08-10',
},
{
url: 'https://support.claude.com/en/articles/12111783-create-and-edit-files-with-claude',
label: 'Create and edit files with Claude (network egress settings)',
asOf: '2026-08-10',
},
{
url: 'https://support.claude.com/en/articles/13455879-use-claude-cowork-on-team-and-enterprise-plans',
label: 'Use Claude Cowork on Team and Enterprise plans',
asOf: '2026-08-10',
},
],
},
apiPublishing: {
value: 'No',
detail:
Expand Down Expand Up @@ -901,6 +926,21 @@ export const claudeCoworkProfile: CompetitorProfile = {
},
],
},
sessionPolicy: {
value:
'Partial: the setting is available only to "Admins and Owners of Enterprise plans and Console Admins," who can enable a shortened session length of 1, 7, 14, or 28 days (Console Admins get 1, 3, or 7 days), after which "users will need to sign in again after the specified period, even if they\'ve been actively using Claude." This is an absolute lifetime cap from sign-in, not an inactivity timeout, and no idle timeout is documented.',
detail:
"Because the control is Enterprise/Console-gated, administrators on other plans cannot set a session lifetime at all; with the setting disabled, sessions return to the default behavior of remaining active as long as the user stays active, with no documented idle timeout. Because one session spans all of a user's organizations, the shortest configured duration across them applies. Disabling the setting does not retroactively extend sessions already scheduled to expire.",
shortValue: 'Partial: Enterprise/Console only, 1/7/14/28-day absolute cap',
confidence: 'verified',
sources: [
{
url: 'https://support.claude.com/en/articles/13163631-configuring-session-security-settings',
label: 'Configuring session security settings',
asOf: '2026-08-10',
},
],
},
thirdPartyVetting: {
value:
"Partial: Anthropic maintains first-party catalogs (anthropics/skills, anthropics/knowledge-work-plugins, the 11 plugins bundled into Cowork), but the plugin/skill ecosystem is open by design. Any developer can host a plugin marketplace as a git repo, and users add it via `/plugin marketplace add`, with no Anthropic approval queue or review gate before installation. A third-party security audit has already found malicious entries in that broader ecosystem: Snyk's ToxicSkills research scanned ~3,984 skills on ClawHub and skills.sh (third-party marketplaces that also serve Claude Code users) and confirmed 76 malicious skills, with 1,467 flagged for security issues.",
Expand Down
55 changes: 55 additions & 0 deletions apps/sim/lib/compare/data/competitors/crewai.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -654,6 +654,36 @@ export const crewaiProfile: CompetitorProfile = {
},
],
},
codeSandboxRuntime: {
value:
'Partial: CrewAI no longer ships a sandbox of its own. The Docker-backed CodeInterpreterTool was removed from crewai-tools in April 2026 and the docs now direct users to a third-party sandbox service, so the execution environment is configured in that provider. What remains first-party is AMP deployment: a deployed crew installs whatever the project declares in pyproject.toml/uv.lock, including private-registry packages.',
detail:
"The CodeInterpreterTool page now carries a deprecation warning stating that the tool 'has been removed from crewai-tools' and that the allow_code_execution and code_execution_mode parameters on Agent are also deprecated, directing users to a dedicated sandbox service (E2B or Modal) instead; CERT/CC VU#221883 records the same vendor statement, that the tool including its Docker sandbox and its restricted-Python fallback was removed in response to code-execution vulnerabilities. In its place crewai-tools ships wrappers for third-party sandboxes (e2b_sandbox_tool, daytona_sandbox_tool), so image, package, and resource configuration follow that provider's model and account rather than CrewAI's. Separately, a crew deployed to CrewAI AMP is built from the repository's own pyproject.toml with a required uv.lock, so the deployed runtime contains the packages the developer declared, including packages from a private registry configured through [[tool.uv.index]] plus UV_INDEX_*_USERNAME/PASSWORD environment variables. Outside AMP, CrewAI is a Python library with no sandbox of its own: crew code runs in whatever interpreter and virtualenv the developer starts it in, so the dependency set is fully theirs to control and equally unisolated.",
shortValue: 'Partial, AMP deploy dependencies; code sandbox delegated to E2B/Daytona',
confidence: 'verified',
sources: [
{
url: 'https://docs.crewai.com/en/tools/ai-ml/codeinterpretertool',
label: 'Code Interpreter (removal notice) - CrewAI Docs',
asOf: '2026-08-10',
},
{
url: 'https://www.kb.cert.org/vuls/id/221883',
label: 'VU#221883 vendor statement - CERT Coordination Center',
asOf: '2026-08-10',
},
{
url: 'https://docs-platform.crewai.com/platform/en/guides/deploy-to-amp',
label: 'Deploy to AMP - CrewAI Platform Docs',
asOf: '2026-08-10',
},
{
url: 'https://docs-platform.crewai.com/platform/en/guides/private-package-registry',
label: 'Private Package Registries - CrewAI Platform Docs',
asOf: '2026-08-10',
},
],
},
apiPublishing: {
value: 'Yes: CrewAI AMP deploys a crew as a callable REST API (kickoff/status endpoints)',
detail:
Expand Down Expand Up @@ -905,6 +935,31 @@ export const crewaiProfile: CompetitorProfile = {
},
],
},
sessionPolicy: {
value:
"Not publicly documented: no admin-configurable session lifetime or idle timeout appears in CrewAI AMP's public docs; the SSO, RBAC, and self-hosted configuration pages name no session control",
detail:
"CrewAI's platform SSO page documents WorkOS (the SaaS default), Microsoft Entra ID, Okta, Auth0, and Keycloak as identity providers and delegates MFA enforcement to the IdP, but names no session-lifetime, absolute-cap, or inactivity-timeout setting; the RBAC permission matrix likewise covers default_settings and organization_settings without a session control. The self-hosted Helm chart's WorkOS variables (WORKOS_CLIENT_ID, WORKOS_AUTHKIT_DOMAIN, WORKOS_COOKIE_PASSWORD, WORKOS_API_KEY) document credentials and cookie encryption but no lifetime or expiry setting. CrewAI does not document where session length is controlled, and no session-duration behavior is stated either way. The open-source framework has no user accounts or sign-in at all, so the question does not apply to it.",
shortValue: 'No documented session-lifetime or idle-timeout setting',
confidence: 'estimated',
sources: [
{
url: 'https://docs-platform.crewai.com/platform/en/features/sso',
label: 'SSO - CrewAI Platform Docs',
asOf: '2026-08-10',
},
{
url: 'https://docs-platform.crewai.com/platform/en/features/rbac',
label: 'RBAC - CrewAI Platform Docs',
asOf: '2026-08-10',
},
{
url: 'https://enterprise-docs.crewai.com/features/workos-sso',
label: 'WorkOS SSO - CrewAI Platform Helm Chart',
asOf: '2026-08-10',
},
],
},
thirdPartyVetting: {
value:
'Partial: the core crewai-tools code is maintainer-reviewed in the main crewAI repo, but the platform Tool Repository lets any org publish public tools with only automated security checks, and CrewAI also supports the open, community-run MCP server ecosystem',
Expand Down
45 changes: 45 additions & 0 deletions apps/sim/lib/compare/data/competitors/dust.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -645,6 +645,31 @@ export const dustProfile: CompetitorProfile = {
},
],
},
codeSandboxRuntime: {
value:
'No: the Computer tool runs agent code inside a Dust-managed isolated environment whose runtime image and libraries Dust controls; admins configure the outbound domain allowlist and DST_*/DSEC_* environment variables, but no documented setting declares npm/PyPI packages, OS-level packages, or additional CLI binaries',
detail:
"Computer is documented as a 'controlled workbench' where an agent runs code, processes files (Excel/CSV, Word, PDF, PowerPoint), and generates artifacts, with no open internet access by default. The configurable surface is network allowlisting (exact domains such as api.openai.com, or wildcards such as *.example.com, approved permanently by a workspace admin or for one conversation by a user), non-sensitive configuration variables (DST_*), HTTPS secret placeholders substituted only on approved outbound requests (DSEC_*), and a built-in dsbx CLI. The admin setup page for Computer enumerates the admin surface as exactly two areas, network access and environment variables; no package manifest, dependency declaration, or custom-image option is documented on either page.",
shortValue: 'Dust-managed sandbox image; only network and env vars are configurable',
confidence: 'verified',
sources: [
{
url: 'https://docs.dust.tt/docs/user-documentation/admins/tools-management/computer-admin-setup.md',
label: 'Computer Admin Setup | Dust Docs',
asOf: '2026-08-10',
},
{
url: 'https://docs.dust.tt/docs/computer',
label: 'Computer | Dust Docs',
asOf: '2026-08-10',
},
{
url: 'https://docs.dust.tt/docs/tools',
label: 'Tools | Dust Docs',
asOf: '2026-08-10',
},
],
},
apiPublishing: {
value:
'Yes: a documented Conversation API lets external applications create conversations and post messages to Dust agents programmatically, and a Developer Platform covers broader API access',
Expand Down Expand Up @@ -901,6 +926,26 @@ export const dustProfile: CompetitorProfile = {
},
],
},
sessionPolicy: {
value:
'Not publicly documented: Dust documents SAML SSO with workspace-wide enforcement and SCIM provisioning on the Enterprise plan, but no admin-configurable absolute session lifetime or idle timeout, and no fixed session length is published either',
detail:
"Dust's workspace governance docs describe the admin surface under Admin > People & Security as managing security settings, user access, identity verification, and provisioning; neither those pages nor the SSO/SAML pages describe a session-duration, idle-timeout, or forced re-authentication setting. Enforcing SSO restricts which login methods are accepted (users can no longer sign in with social accounts) rather than how long a signed-in session lasts, so session length in practice follows whatever the upstream identity provider enforces at re-authentication.",
shortValue: 'No documented session-lifetime or idle-timeout setting',
confidence: 'estimated',
sources: [
{
url: 'https://docs.dust.tt/docs/user-documentation/admins/admin-governance/workspace-governance-roles-groups-and-permissions.md',
label: 'Workspace Governance (Roles, Groups & Permissions) | Dust Docs',
asOf: '2026-08-10',
},
{
url: 'https://docs.dust.tt/docs/user-documentation/admins/admin-governance/single-sign-on-sso/saml-sso.md',
label: 'SAML SSO | Dust Docs',
asOf: '2026-08-10',
},
],
},
thirdPartyVetting: {
value:
'Partial: native data connections (11 fully-managed sources including Google Drive, Notion, Confluence, GitHub, Salesforce, Microsoft, Snowflake, BigQuery, Zendesk, Gong, and Intercom) are first-party and built/maintained by the Dust team; Slack and dozens of other business tools (Airtable, Asana, HubSpot, Jira, Salesloft, and more) are documented as separate MCP-based Tools rather than native Connections, and agent tools can also be extended with any external MCP server by pasting its public URL, with no Dust-led vetting or review of that server',
Expand Down
Loading
Loading