From 24848f4362c2fd81cba3338f3705e6c583942a5c Mon Sep 17 00:00:00 2001 From: Waleed Latif Date: Mon, 10 Aug 2026 18:18:03 -0700 Subject: [PATCH 1/2] feat(comparisons): add code-sandbox and session-policy rows Add two comparison rows covering configurable code sandboxes and admin-configurable session policy, populated for Sim and all 20 competitor profiles. Source Sim's facts from the docs rather than the codebase, and repoint the execution-limits row at the Run Time Limits table. --- .../comparisons/comparison-sections.ts | 2 + .../compare/data/competitors/claude-cowork.ts | 40 ++++++++++++ .../lib/compare/data/competitors/crewai.ts | 55 ++++++++++++++++ apps/sim/lib/compare/data/competitors/dust.ts | 45 +++++++++++++ .../lib/compare/data/competitors/flowise.ts | 52 +++++++++++++++ .../lib/compare/data/competitors/gumloop.ts | 45 +++++++++++++ .../lib/compare/data/competitors/langchain.ts | 55 ++++++++++++++++ .../lib/compare/data/competitors/langflow.ts | 45 +++++++++++++ apps/sim/lib/compare/data/competitors/make.ts | 31 +++++++++ .../data/competitors/microsoft-copilot.ts | 42 ++++++++++++ apps/sim/lib/compare/data/competitors/n8n.ts | 55 ++++++++++++++++ .../data/competitors/openai-agentkit.ts | 50 ++++++++++++++ .../lib/compare/data/competitors/openclaw.ts | 40 ++++++++++++ .../lib/compare/data/competitors/pipedream.ts | 65 +++++++++++++++++++ .../data/competitors/power-automate.ts | 58 +++++++++++++++++ .../lib/compare/data/competitors/retool.ts | 51 +++++++++++++++ .../lib/compare/data/competitors/stackai.ts | 50 ++++++++++++++ .../sim/lib/compare/data/competitors/tines.ts | 51 ++++++++++++++- .../lib/compare/data/competitors/vellum.ts | 57 ++++++++++++++++ .../lib/compare/data/competitors/workato.ts | 45 +++++++++++++ .../lib/compare/data/competitors/zapier.ts | 37 +++++++++++ apps/sim/lib/compare/data/feature-catalog.ts | 40 +++++++++++- apps/sim/lib/compare/data/sim.ts | 47 ++++++++++++-- apps/sim/lib/compare/data/types.ts | 4 ++ 24 files changed, 1050 insertions(+), 12 deletions(-) diff --git a/apps/sim/app/(landing)/comparisons/comparison-sections.ts b/apps/sim/app/(landing)/comparisons/comparison-sections.ts index 825abdfa23d..adebba03394 100644 --- a/apps/sim/app/(landing)/comparisons/comparison-sections.ts +++ b/apps/sim/app/(landing)/comparisons/comparison-sections.ts @@ -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' }, @@ -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' }, diff --git a/apps/sim/lib/compare/data/competitors/claude-cowork.ts b/apps/sim/lib/compare/data/competitors/claude-cowork.ts index 786c7c99e58..520bf5550d4 100644 --- a/apps/sim/lib/compare/data/competitors/claude-cowork.ts +++ b/apps/sim/lib/compare/data/competitors/claude-cowork.ts @@ -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: @@ -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.", diff --git a/apps/sim/lib/compare/data/competitors/crewai.ts b/apps/sim/lib/compare/data/competitors/crewai.ts index 5d6327facb0..811898524c2 100644 --- a/apps/sim/lib/compare/data/competitors/crewai.ts +++ b/apps/sim/lib/compare/data/competitors/crewai.ts @@ -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: @@ -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', diff --git a/apps/sim/lib/compare/data/competitors/dust.ts b/apps/sim/lib/compare/data/competitors/dust.ts index 3f4aaba8ae9..5ebf1328fe4 100644 --- a/apps/sim/lib/compare/data/competitors/dust.ts +++ b/apps/sim/lib/compare/data/competitors/dust.ts @@ -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', @@ -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', diff --git a/apps/sim/lib/compare/data/competitors/flowise.ts b/apps/sim/lib/compare/data/competitors/flowise.ts index e360f4998af..eda221873d5 100644 --- a/apps/sim/lib/compare/data/competitors/flowise.ts +++ b/apps/sim/lib/compare/data/competitors/flowise.ts @@ -534,6 +534,38 @@ export const flowiseProfile: CompetitorProfile = { }, ], }, + codeSandboxRuntime: { + value: + 'Partial: self-hosted only and at the image level. The runtime available to Custom JS Function and Custom Tool code is controlled by server environment variables: TOOL_FUNCTION_BUILTIN_DEP (which NodeJS built-in modules code may require, set to crypto,fs in the shipped .env.example and documented as accepting * for all builtins), TOOL_FUNCTION_EXTERNAL_DEP (which npm packages are importable, set to moment,lodash,pg,mysql2,mongodb,ioredis,redis,typeorm,@zilliz/milvus2-sdk-node in the same file), and ALLOW_BUILTIN_DEP, which the docs describe as allowing the project dependencies already bundled with Flowise to be used, illustrated with cheerio and typeorm. Adding an npm package that is not already bundled requires adding it to packages/components, rebuilding Flowise, and restarting the server, so it is a redeploy of your own image rather than a per-step dependency declaration; there is no runtime npm install inside the code node, and no documented way to declare OS-level system packages or preinstalled CLI binaries. Flowise does not document any way for users of the managed Flowise Cloud product to set these server environment variables.', + detail: + 'The Custom Tool docs describe the workflow explicitly: add the package under packages/components with pnpm add, run pnpm build, "then, add the imported libraries to TOOL_FUNCTION_EXTERNAL_DEP environment variable", then restart the application. TOOL_FUNCTION_BUILTIN_DEP is additive rather than a replacement: packages/components/src/utils.ts concatenates it onto a hardcoded defaultAllowBuiltInDep list (assert, buffer, crypto, events, path, querystring, timers, url, zlib), so the shipped crypto,fs value widens that base set rather than defining it; TOOL_FUNCTION_EXTERNAL_DEP is additive in the same way, layered onto a defaultAllowExternalDependencies list of axios and node-fetch. Python is not a supported code-step runtime at all, so the configurable surface is Node-only.', + shortValue: 'Self-hosted only: env-var allowlists plus a rebuild; no Cloud control', + confidence: 'verified', + sources: [ + { + url: 'https://docs.flowiseai.com/configuration/environment-variables', + label: + 'Flowise Docs: Environment Variables (TOOL_FUNCTION_BUILTIN_DEP, TOOL_FUNCTION_EXTERNAL_DEP, ALLOW_BUILTIN_DEP)', + asOf: '2026-08-10', + }, + { + url: 'https://docs.flowiseai.com/integrations/langchain/tools/custom-tool', + label: 'Flowise Docs: Custom Tool (adding external npm dependencies)', + asOf: '2026-08-10', + }, + { + url: 'https://raw.githubusercontent.com/FlowiseAI/Flowise/main/packages/server/.env.example', + label: 'GitHub: Flowise packages/server/.env.example (shipped dependency allowlists)', + asOf: '2026-08-10', + }, + { + url: 'https://github.com/FlowiseAI/Flowise/blob/main/packages/components/src/utils.ts', + label: + 'GitHub: packages/components/src/utils.ts (defaultAllowBuiltInDep, defaultAllowExternalDependencies, additive allowlists)', + asOf: '2026-08-10', + }, + ], + }, apiPublishing: { value: 'Yes: any chatflow can be called as a REST API via /api/v1/prediction/{chatflowId}, with client code generated for Python, JavaScript, and cURL, and sessionId support for maintaining conversation context.', @@ -755,6 +787,26 @@ export const flowiseProfile: CompetitorProfile = { }, ], }, + sessionPolicy: { + value: + 'Partial: self-hosted server environment variables rather than an admin-console setting. JWT_TOKEN_EXPIRY_IN_MINUTES sets the access-token lifetime and JWT_REFRESH_TOKEN_EXPIRY_IN_MINUTES sets the refresh-token lifetime, which together bound how long a sign-in survives, and EXPIRE_AUTH_TOKENS_ON_RESTART invalidates all tokens on server restart. No idle/inactivity timeout is documented, and Flowise does not document any equivalent control for admins of the managed Flowise Cloud product.', + detail: + 'The shipped .env.example sets JWT_TOKEN_EXPIRY_IN_MINUTES=360 and JWT_REFRESH_TOKEN_EXPIRY_IN_MINUTES=43200 (30 days); the Application authorization docs page instead cites defaults of 60 minutes and 129,600 minutes (90 days), so the documented default differs from the shipped one. Because these are process environment variables, changing them is a deploy-level action for the whole instance, not a per-organization policy an account admin can set from the Workspaces UI.', + shortValue: 'Self-hosted JWT expiry env vars; no idle timeout, no documented Cloud control', + confidence: 'verified', + sources: [ + { + url: 'https://docs.flowiseai.com/configuration/authorization/app-level', + label: 'Flowise Docs: Application authorization (JWT expiry and session variables)', + asOf: '2026-08-10', + }, + { + url: 'https://raw.githubusercontent.com/FlowiseAI/Flowise/main/packages/server/.env.example', + label: 'GitHub: Flowise packages/server/.env.example (shipped JWT expiry defaults)', + asOf: '2026-08-10', + }, + ], + }, thirdPartyVetting: { value: "Yes: Flowise's nodes (LLMs, tools, vector stores, document loaders) live in the packages/components/nodes folder of the core FlowiseAI/Flowise monorepo. New nodes are contributed via GitHub pull request and reviewed/merged by the Flowise team before shipping in an official release, rather than published independently by third parties into an open, unreviewed marketplace. The separate Marketplace feature distributes JSON chatflow/agentflow templates, not installable executable code.", diff --git a/apps/sim/lib/compare/data/competitors/gumloop.ts b/apps/sim/lib/compare/data/competitors/gumloop.ts index 71fe435f9be..936f979c68f 100644 --- a/apps/sim/lib/compare/data/competitors/gumloop.ts +++ b/apps/sim/lib/compare/data/competitors/gumloop.ts @@ -651,6 +651,31 @@ export const gumloopProfile: CompetitorProfile = { confidence: 'estimated', sources: [{ url: 'https://docs.gumloop.com/', label: 'Gumloop docs', asOf: '2026-07-02' }], }, + codeSandboxRuntime: { + value: + 'No: the Run Code node executes against a fixed, Gumloop-controlled runtime. Users import from a vendor-curated preinstalled list (Python: pandas, numpy, scipy, xarray, opencv-python, scikit-image, scikit-learn, nltk, spacy, beautifulsoup4, requests, aiohttp, matplotlib, plotly, openpyxl, python-docx, librosa and others published at a Gumloop-hosted requirements.txt; JavaScript: the `ai` SDK plus @ai-sdk/openai, azure, anthropic, amazon-bedrock, google, google-vertex, mistral, cohere and groq). There is no documented way to declare npm/PyPI dependencies, install OS-level system packages, or specify CLI binaries for the runtime.', + detail: + 'Gumloop docs describe importing packages only via a plain `import` (Python) or `require` (JavaScript) statement drawn from the published list, with no pip/npm install step. Custom Nodes run in what the docs call "an isolated virtual environment with a 5-minute runtime limit" but likewise document no dependency declaration. On the Gumloop forum, a staff member responding to a Run Code failure caused by unavailable libraries pointed the user back to the published list and suggested a Custom Node as a workaround rather than any package-installation path. Gumloop also ships no downloadable self-managed install of the core platform (see platform.selfHostOption), and its enterprise VPC deployment is operated by Gumloop, so no customer-supplied runtime image is documented there either.', + shortValue: 'No: fixed runtime, vendor-curated preinstalled packages', + confidence: 'verified', + sources: [ + { + url: 'https://docs.gumloop.com/nodes/advanced/run_code', + label: 'Run Code - Gumloop docs', + asOf: '2026-08-10', + }, + { + url: 'https://docs.gumloop.com/nodes/custom_node_details', + label: 'Custom Node Builder - Gumloop docs', + asOf: '2026-08-10', + }, + { + url: 'https://forum.gumloop.com/t/run-code-node-fails-with-generic-error-likely-missing-libraries/2133', + label: 'Gumloop forum: Run Code node missing libraries', + asOf: '2026-08-10', + }, + ], + }, apiPublishing: { value: 'Yes: flows can be triggered via REST API and a JavaScript SDK; agents embedded in a flow can be called via the same API', @@ -953,6 +978,26 @@ export const gumloopProfile: CompetitorProfile = { }, ], }, + sessionPolicy: { + value: + 'Not publicly documented: no admin-configurable session lifetime or idle timeout appears in Gumloop\'s public documentation. The only primary-source statement is a single bullet on the Enterprise SSO page listing "Session Management: Configurable session timeouts and secure token handling." No admin setting name, configuration steps, default session lifetime, idle-timeout value, or absolute-cap value is published anywhere in Gumloop\'s docs, security page, or trust center.', + detail: + "The bullet sits in a Security & Compliance list introduced as \"Gumloop's SSO implementation follows industry security standards\", alongside SOC 2 Type II certification, SAML 2.0 and TLS 1.3 entries that are compliance assurances rather than admin-configurable settings, so it does not establish a customer-facing control. The same page documents its actual admin controls in detail, including per-direction SCIM mapping-table toggles, name-based mapping mode, and named audit events, but describes no session setting; it gates SAML and SCIM settings to the Admin organization role and an Enterprise subscription, so any such control would be Enterprise-tier. Gumloop's public security page and trust center make no mention of session lifetime, idle timeout, or forced re-authentication. Because SAML SSO is available, organizations can also inherit re-authentication frequency from their upstream IdP, but that is the IdP's policy rather than a Gumloop-enforced one.", + shortValue: 'Single SSO-page bullet cites configurable timeouts; no setting documented', + confidence: 'estimated', + sources: [ + { + url: 'https://docs.gumloop.com/enterprise-features/sso_saml_scim', + label: 'SSO, SAML & SCIM - Gumloop docs', + asOf: '2026-08-10', + }, + { + url: 'https://www.gumloop.com/solutions/security', + label: 'Security and trust at Gumloop', + asOf: '2026-08-10', + }, + ], + }, thirdPartyVetting: { value: "Yes: Gumloop's 100+ built-in integrations are first-party nodes authored and maintained by Gumloop. Custom Nodes (user-written code steps) are built privately per account or team and shared only with named teammates or an org/link, not published to a public, searchable registry of third-party installable nodes. The separate Community Templates gallery is workflow templates built from Gumloop's own nodes, and submissions go through a Gumloop content-quality review before listing.", diff --git a/apps/sim/lib/compare/data/competitors/langchain.ts b/apps/sim/lib/compare/data/competitors/langchain.ts index 2bd50437677..7c5b3e90b19 100644 --- a/apps/sim/lib/compare/data/competitors/langchain.ts +++ b/apps/sim/lib/compare/data/competitors/langchain.ts @@ -631,6 +631,41 @@ export const langchainProfile: CompetitorProfile = { confidence: 'verified', sources: [], }, + codeSandboxRuntime: { + value: + 'Yes: LangSmith Sandboxes let a team supply their own Docker image ("Bring your own image. Define dependencies, CPU, and memory in a Docker image, then reuse it across sandboxes"), including images pulled from a private registry. A snapshot is built by pointing at any Docker image, or captured from a running sandbox after packages have been installed in it, and sandboxes then boot from that snapshot.', + detail: + "Two distinct runtimes should not be conflated. LangGraph node code itself is not sandboxed at all: it executes in the developer's own Python/Node process, so the dependency set is whatever their own requirements.txt or package.json declares and there is no isolation boundary between agent code and the host. Sandboxes are a separate, opt-in execution surface (billed on the LangSmith pricing page at sandbox CPU/memory/storage rates) for code the agent generates or for risky filesystem work; they reached general availability in May 2026 after a waitlisted private preview, and the docs list them as generally available on the US, EU, and APAC GCP environments, on AWS US, and on self-hosted deployments. The docs describe a snapshot as 'a reusable filesystem bundle backed by a Docker image', built with a docker_image argument plus an fs_capacity_bytes size, and optionally a registry_id referencing stored private-registry credentials. The Deep Agents harness can back the same abstraction with third-party sandbox providers instead (Daytona, E2B, Modal, Runloop, Vercel, AWS AgentCore, NVIDIA OpenShell) or a custom backend the developer implements, in which case the image and dependency configuration follow that provider's model.", + shortValue: 'Yes, LangSmith Sandboxes take a bring-your-own Docker image', + confidence: 'verified', + sources: [ + { + url: 'https://www.langchain.com/langsmith/sandboxes', + label: 'LangSmith Sandboxes | Secure Runtime for Agent Code', + asOf: '2026-08-10', + }, + { + url: 'https://docs.langchain.com/langsmith/sandbox-snapshots', + label: 'Sandbox snapshots - Docs by LangChain', + asOf: '2026-08-10', + }, + { + url: 'https://docs.langchain.com/langsmith/sandboxes', + label: 'LangSmith Sandboxes (environment availability) - Docs by LangChain', + asOf: '2026-08-10', + }, + { + url: 'https://www.langchain.com/blog/langsmith-sandboxes-generally-available', + label: 'LangSmith Sandboxes are Generally Available (LangChain Blog)', + asOf: '2026-08-10', + }, + { + url: 'https://docs.langchain.com/oss/python/deepagents/sandboxes', + label: 'Sandboxes - Docs by LangChain', + asOf: '2026-08-10', + }, + ], + }, apiPublishing: { value: 'Yes: the LangGraph Agent Server exposes deployed graphs over a REST API, and additionally supports A2A as a callable interface for the same deployed agent', @@ -898,6 +933,26 @@ export const langchainProfile: CompetitorProfile = { }, ], }, + sessionPolicy: { + value: + 'Partial: self-hosted LangSmith only. An operator sets the maximum session length via the OAUTH_SESSION_MAX_SEC environment variable when using OAuth 2.0/SSO, or BASIC_AUTH_JWT_EXPIRATION_SECONDS when using basic authentication, both defaulting to 28800 seconds (8 hours). No equivalent admin-configurable session control is documented for LangSmith Cloud.', + detail: + 'Both settings are an absolute cap on session lifetime from sign-in; no separate inactivity/idle timeout is documented. On the cloud product, LangChain support states that after a SAML assertion is validated the session token (a JWT) is issued by LangSmith\'s own auth layer rather than the IdP, and that this "is by design and is not configurable", so an upstream IdP session policy does not govern the resulting LangSmith session either.', + shortValue: 'Self-hosted env vars (8h default); not configurable on cloud', + confidence: 'verified', + sources: [ + { + url: 'https://support.langchain.com/articles/9515017706-session-timeout-configuration-for-langsmith-self-hosted', + label: 'Session Timeout Configuration for LangSmith Self-Hosted', + asOf: '2026-08-10', + }, + { + url: 'https://support.langchain.com/articles/8821869322-sso-authentication-and-token-issuance-in-langsmith', + label: 'SSO Authentication and Token Issuance in LangSmith', + asOf: '2026-08-10', + }, + ], + }, thirdPartyVetting: { value: "Partial: the core langchain and langchain-core packages plus a set of popular integrations are maintained and security-reviewed by LangChain's own team, but the much larger integration surface lives in the community-driven langchain-community package (and hundreds of separately published community PyPI packages), which LangChain's own security policy states is not eligible for its bug bounty program", diff --git a/apps/sim/lib/compare/data/competitors/langflow.ts b/apps/sim/lib/compare/data/competitors/langflow.ts index f9d41991de7..c481c2f9548 100644 --- a/apps/sim/lib/compare/data/competitors/langflow.ts +++ b/apps/sim/lib/compare/data/competitors/langflow.ts @@ -560,6 +560,31 @@ export const langflowProfile: CompetitorProfile = { }, ], }, + codeSandboxRuntime: { + value: + 'Partial: on self-hosted deployments only, the Python environment custom components run in is user-configurable. Langflow Desktop reads a `requirements.txt` in its data directory (`~/.langflow/data/requirements.txt` on macOS) where dependencies are pinned as `DEPENDENCY==VERSION`; Langflow OSS accepts `uv add DEPENDENCY` in a cloned repo and optional dependency groups via pip extras such as `langflow[postgresql]`; and a custom Docker image built on `langflowai/langflow:latest` can layer a `pyproject.toml` plus `uv.lock` for extra packages and mount custom component folders via `LANGFLOW_COMPONENTS_PATH`. Extension packages are pip-installable and register their bundles into the component palette when the server starts. No equivalent dependency configuration is documented for the managed Langflow Cloud.', + detail: + "This is environment configuration at the deployment level, not a per-step sandbox: packages are declared for the whole Langflow server and applied on restart, and there is no documented per-flow or per-component isolation boundary. Langflow's own Security page states it does not enforce isolation between users in a single process or restrict local disk and network access, so component code runs at the same trust level as the server.", + shortValue: 'Self-hosted only: requirements.txt, uv, or a custom Docker image', + confidence: 'verified', + sources: [ + { + url: 'https://docs.langflow.org/install-custom-dependencies', + label: 'Langflow Docs: Install custom dependencies', + asOf: '2026-08-10', + }, + { + url: 'https://docs.langflow.org/develop-application', + label: 'Langflow Docs: Containerize a Langflow application', + asOf: '2026-08-10', + }, + { + url: 'https://docs.langflow.org/extensions-overview', + label: 'Langflow Docs: Extensions overview', + asOf: '2026-08-10', + }, + ], + }, apiPublishing: { value: "Yes: any flow can be called as a REST API via documented run endpoints, with an auto-generated API reference (OpenAPI spec) available at the deployment's docs endpoint.", @@ -784,6 +809,26 @@ export const langflowProfile: CompetitorProfile = { confidence: 'unknown', sources: [], }, + sessionPolicy: { + value: + 'Partial: on self-hosted deployments only, via environment variables. Langflow issues short-lived JWTs and exposes `LANGFLOW_ACCESS_TOKEN_EXPIRE_SECONDS` (default 3600, one hour) and `LANGFLOW_REFRESH_TOKEN_EXPIRE_SECONDS` (default 604800, seven days), so an operator sets the absolute ceiling on how long a signed-in session survives before re-authentication. No inactivity or idle timeout setting is documented, and no admin-console UI for setting session policy across an organization is documented for Langflow Cloud.', + detail: + 'Expiry is measured from token issuance rather than last activity, and clients silently exchange a refresh token at `/api/v1/refresh`, so the effective session cap is the refresh token lifetime. Because these are process environment variables, the policy is set by whoever operates the deployment rather than by an administrator inside the product.', + shortValue: 'Self-hosted only, via token-expiry env variables', + confidence: 'verified', + sources: [ + { + url: 'https://docs.langflow.org/api-keys-and-authentication', + label: 'Langflow Docs: API keys and authentication', + asOf: '2026-08-10', + }, + { + url: 'https://docs.langflow.org/authentication-overview', + label: 'Langflow Docs: Authentication and authorization overview', + asOf: '2026-08-10', + }, + ], + }, thirdPartyVetting: { value: 'Partial: Langflow disclosed CVE-2025-3248, an unauthenticated remote code execution flaw in the custom-component code-validation endpoint, fixed in version 1.3.0; security researchers confirmed it was actively exploited in the wild to deploy the Flodrix botnet on unpatched instances before the fix shipped. That incident reflects the underlying trust model: built-in integration bundles are contributed by third-party contributors as pull requests to the official langflow-ai/langflow codebase and reviewed and merged by core maintainers, but Langflow also ships a custom-component system that lets any user author and run their own Python code with full server access, the same trust level as the core server itself.', diff --git a/apps/sim/lib/compare/data/competitors/make.ts b/apps/sim/lib/compare/data/competitors/make.ts index 210142f1369..d85f6158560 100644 --- a/apps/sim/lib/compare/data/competitors/make.ts +++ b/apps/sim/lib/compare/data/competitors/make.ts @@ -695,6 +695,22 @@ export const makeProfile: CompetitorProfile = { { url: 'https://apps.make.com/code', label: 'Make Code app docs', asOf: '2026-07-08' }, ], }, + codeSandboxRuntime: { + value: + "Partial: Enterprise-only and at the package layer. The Make Code module has an 'Additional dependencies (Enterprise plans only)' field under Advanced settings where third-party JavaScript/Python packages are declared by name (Make's own example adds axios, then requires it in the code) and installed before the code runs. On Core, Pro, and Teams the runtime is a fixed image limited to Make's standard libraries: moment, moment-timezone, and lodash for JavaScript, and pendulum, toolz, and requests for Python. Make's documentation lists no field for OS-level system packages, custom container images, or preinstalled CLI binaries on any plan.", + detail: + 'Per the Make Code app documentation, declared dependencies are installed before execution and are not shared between multiple Code modules. The sandbox itself is sized by plan rather than by the user: 1 CPU, 512 MB RAM, and a 30-second maximum execution time on Core/Pro/Teams, rising to 2 CPUs, 1024 MB RAM, and 300 seconds on Enterprise. Runtimes are pinned by Make (Python 3.12.11, Node 20.19.4) rather than chosen per module, and because Make is cloud-only with no self-hosted engine, there is no path to bake a custom runtime image. Make documents the Code app as being in open beta, noting that both functionality and pricing may change.', + shortValue: 'Packages only: declared npm/PyPI dependencies, Enterprise plans', + confidence: 'verified', + sources: [ + { url: 'https://apps.make.com/code', label: 'Make Code app docs', asOf: '2026-08-10' }, + { + url: 'https://www.make.com/en/blog/make-code-app', + label: 'Make blog: Make Code App', + asOf: '2026-08-10', + }, + ], + }, apiPublishing: { value: 'Yes, via custom + response webhooks acting as API endpoints; plus a separate Make platform REST API', @@ -1024,6 +1040,21 @@ export const makeProfile: CompetitorProfile = { }, ], }, + sessionPolicy: { + value: + "Yes: organization administrators and owners can set a session timeout from the organization dashboard (three dots next to Organization settings > Set session timeout), choosing how long users can be inactive before they are automatically logged out, anywhere from 15 minutes to 7 days. This is an inactivity/idle timeout applied org-wide; Make's help center documents no separate absolute session-lifetime cap measured from sign-in.", + detail: + "The setting is restricted to organization administrators and owners, and where a user belongs to multiple organizations the shortest configured timeout applies to that user. Make's help page does not restrict the control to a specific pricing tier. Separately, closing the browser ends the session regardless of the configured timeout value.", + shortValue: 'Yes: org-wide idle timeout, 15 minutes to 7 days', + confidence: 'verified', + sources: [ + { + url: 'https://help.make.com/set-the-length-of-your-session-timeout', + label: 'Set the length of your session timeout - Make Help Center', + asOf: '2026-08-10', + }, + ], + }, thirdPartyVetting: { value: 'Partial: any developer can build a custom Make app, but publishing it to the public Apps Marketplace requires passing a Make QA code review before it becomes available to all users', diff --git a/apps/sim/lib/compare/data/competitors/microsoft-copilot.ts b/apps/sim/lib/compare/data/competitors/microsoft-copilot.ts index e3601495b91..716d2fe8b9e 100644 --- a/apps/sim/lib/compare/data/competitors/microsoft-copilot.ts +++ b/apps/sim/lib/compare/data/competitors/microsoft-copilot.ts @@ -766,6 +766,26 @@ export const microsoftCopilotProfile: CompetitorProfile = { }, ], }, + codeSandboxRuntime: { + value: + "No: code interpreter, Copilot Studio's Python execution engine for prompts, runs generated code in a Microsoft-hosted environment whose compute is ephemeral, created during a session and disposed of afterward. There is no documented way to declare third-party packages, OS-level system packages, or CLI binaries for that environment, and Microsoft documents restrictions on external network access.", + detail: + "Administrator control over code interpreter is a per-environment on/off switch (off by default, set in the Power Platform admin center or via the CopilotStudio_CodeInterpreter environment property), not runtime configuration. Microsoft's FAQ describes execution as sandboxed and isolated 'to prevent unsafe operations such as network access, system-level commands, or unauthorized file operations,' and neither the Copilot Studio nor the developer documentation publishes a preinstalled-library list or a package-installation mechanism. Because Copilot Studio has no self-hosted deployment, there is also no option to build a custom runtime image; bespoke dependencies have to move out into a custom connector fronting a customer-hosted Azure Function.", + shortValue: 'No: fixed Microsoft-hosted Python sandbox, no package configuration', + confidence: 'verified', + sources: [ + { + url: 'https://learn.microsoft.com/en-us/microsoft-copilot-studio/faq-code-interpreter', + label: 'FAQ for code interpreter - Microsoft Copilot Studio | Microsoft Learn', + asOf: '2026-08-10', + }, + { + url: 'https://learn.microsoft.com/en-us/power-apps/developer/data-platform/code-interpreter', + label: 'Code interpreter for developers - Power Apps | Microsoft Learn', + asOf: '2026-08-10', + }, + ], + }, apiPublishing: { value: 'Yes: a published agent is reachable over the Azure Bot Service Direct Line API/channel, giving external code a callable HTTP interface into the conversation, alongside the standard chat channels', @@ -1077,6 +1097,28 @@ export const microsoftCopilotProfile: CompetitorProfile = { }, ], }, + sessionPolicy: { + value: + 'Partial: at the Microsoft identity and Power Platform layers rather than in Copilot Studio itself. Microsoft Entra ID Conditional Access sign-in frequency policies let an admin set how long a user can access a resource before signing in again (or require reauthentication every time), and a Power Platform admin can separately turn on Session Expiration (60 to 1,440 minutes) plus an Inactivity timeout (minimum 5 minutes) per environment under Settings > Product > Privacy + Security', + detail: + "Copilot Studio exposes no admin-configurable user-session-lifetime setting of its own and inherits the tenant Entra ID session policy, whose default is a rolling 90-day sign-in frequency window with a 90-day refresh-token expiration. The per-environment Session Expiration and Inactivity timeout settings override that default Entra behavior for the environment, though Microsoft documents them against Dataverse-backed customer engagement apps rather than the Copilot Studio maker portal specifically, and lists apps (including Power Apps canvas apps) that don't enforce them. Conditional Access requires a Microsoft Entra ID P1 or P2 license.", + shortValue: 'Via Entra Conditional Access and per-environment timeouts', + confidence: 'verified', + sources: [ + { + url: 'https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-session-lifetime', + label: + 'Conditional Access adaptive session lifetime policies - Microsoft Entra ID | Microsoft Learn', + asOf: '2026-08-10', + }, + { + url: 'https://learn.microsoft.com/en-us/power-platform/admin/user-session-management', + label: + 'Security enhancements for user sessions and access management - Power Platform | Microsoft Learn', + asOf: '2026-08-10', + }, + ], + }, thirdPartyVetting: { value: 'Partial: the primary connector catalog (1,000+ connectors) is Microsoft-certified, requiring code/security review, functional verification, and malware scanning before publication, including connectors submitted by third-party (independent) publishers. But any maker can also build an uncertified custom connector against an arbitrary API for their own tenant, and security researchers at Zenity have shown that custom connectors can bypass Power Platform Data Loss Prevention policies to reach connectors an admin has explicitly blocked', diff --git a/apps/sim/lib/compare/data/competitors/n8n.ts b/apps/sim/lib/compare/data/competitors/n8n.ts index 18322c09408..441e002b667 100644 --- a/apps/sim/lib/compare/data/competitors/n8n.ts +++ b/apps/sim/lib/compare/data/competitors/n8n.ts @@ -709,6 +709,41 @@ export const n8nProfile: CompetitorProfile = { }, ], }, + codeSandboxRuntime: { + value: + "Partial: self-hosted only. On a self-hosted instance an admin sets NODE_FUNCTION_ALLOW_BUILTIN to allowlist Node.js built-in modules (by name, or '*' for all) and NODE_FUNCTION_ALLOW_EXTERNAL to allowlist npm packages by name, with those packages sourced from the instance's n8n/node_modules directory; on n8n Cloud the Code node can't import external npm modules, and n8n makes only the crypto built-in and the moment package available.", + detail: + "The two allowlist variables are instance-level environment variables, not per-workflow settings, and when the instance runs task runners they must be set on the runners rather than the main n8n process. n8n's docs describe the '*' wildcard for the built-in allowlist; the external allowlist is documented as specific module names. Python follows the same host-level pattern: n8n v2 removes the Pyodide-based Python Code node in favour of a native-Python task-runner implementation, and the task-runner variables N8N_RUNNERS_STDLIB_ALLOW and N8N_RUNNERS_EXTERNAL_ALLOW allowlist Python standard-library and third-party modules respectively, so the available Python environment is likewise a property of the host deployment rather than a per-workflow setting. There is no per-code-step declaration of packages, OS packages, or preinstalled CLI binaries; changing the dependency set means changing the host instance.", + shortValue: 'Self-hosted env-var allowlist; Cloud is a fixed image', + confidence: 'verified', + sources: [ + { + url: 'https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/configuration-examples/enable-modules-in-code-node', + label: 'Enable modules in Code node | Deploy | n8n Docs', + asOf: '2026-08-10', + }, + { + url: 'https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.code/', + label: 'Code | Nodes | n8n Docs', + asOf: '2026-08-10', + }, + { + url: 'https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/use-environment-variables/nodes', + label: 'Nodes environment variables | Deploy | n8n Docs', + asOf: '2026-08-10', + }, + { + url: 'https://docs.n8n.io/changelog/v20-breaking-changes', + label: 'v2.0 Breaking changes | Changelog | n8n Docs', + asOf: '2026-08-10', + }, + { + url: 'https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/use-environment-variables/task-runners', + label: 'Task runners environment variables | Deploy | n8n Docs', + asOf: '2026-08-10', + }, + ], + }, apiPublishing: { value: 'Yes: workflows can be triggered/exposed via Webhook trigger as a REST-style endpoint, and via MCP Server Trigger as MCP tools', @@ -1027,6 +1062,26 @@ export const n8nProfile: CompetitorProfile = { }, ], }, + sessionPolicy: { + value: + 'Partial: self-hosted only and env-var driven. N8N_USER_MANAGEMENT_JWT_DURATION_HOURS sets how long a signed-in session JWT lasts (default 168 hours, one week) and N8N_USER_MANAGEMENT_JWT_REFRESH_TIMEOUT_HOURS controls sliding refresh, where 0 means refresh at 25% of the duration and -1 disables refresh so the duration becomes a hard re-login deadline.', + detail: + 'Both are instance-level environment variables set at deploy time rather than an admin console setting, and fractional values (for example 0.5 for 30 minutes) are accepted. The pair was added in n8n 1.26.0 in response to a community request for a session-time limit. Configuring them requires control of the host, so they are not available to n8n Cloud customers, and n8n does not document a Cloud- or Enterprise-tier session-lifetime setting; SAML/OIDC SSO on Business/Enterprise plans handles authentication but n8n does not document inheriting an IdP session lifetime.', + shortValue: 'Self-hosted JWT duration env vars, no Cloud setting', + confidence: 'verified', + sources: [ + { + url: 'https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/use-environment-variables/user-management-and-2fa', + label: 'User management and 2FA | Deploy | n8n Docs', + asOf: '2026-08-10', + }, + { + url: 'https://community.n8n.io/t/setting-to-limit-session-time-for-users-logged-into-n8n-management-console-got-created/30227', + label: 'Setting to limit session time for users logged into n8n (n8n Community)', + asOf: '2026-08-10', + }, + ], + }, thirdPartyVetting: { value: 'Partial: n8n ships built-in first-party nodes plus an open community-node ecosystem published to public npm, where only a subset carry an official "verified" review', diff --git a/apps/sim/lib/compare/data/competitors/openai-agentkit.ts b/apps/sim/lib/compare/data/competitors/openai-agentkit.ts index c902df21996..d66a26c90de 100644 --- a/apps/sim/lib/compare/data/competitors/openai-agentkit.ts +++ b/apps/sim/lib/compare/data/competitors/openai-agentkit.ts @@ -677,6 +677,31 @@ export const openaiAgentkitProfile: CompetitorProfile = { }, ], }, + codeSandboxRuntime: { + value: + "Partial: configurable only on the code-first path. The Agents SDK's sandbox agents let you name the container image the agent's shell and code run in (the documented Docker example passes image: 'node:22-bookworm-slim' to DockerSandboxClient), so third-party packages, OS packages, and CLI binaries come from an image you build and control. The hosted Code Interpreter tool is the opposite: a fixed OpenAI-managed container whose only user-adjustable setting is the memory tier (1g default, 4g, 16g, 64g), with no documented way to declare pip/npm or system packages.", + detail: + "Sandbox execution runs on infrastructure you supply, not OpenAI's: the documented clients are UnixLocalSandboxClient (macOS/Linux) and DockerSandboxClient for local execution, plus hosted providers via BlaxelSandboxClient, CloudflareSandboxClient, DaytonaSandboxClient, E2BSandboxClient, ModalSandboxClient, RunloopSandboxClient, and VercelSandboxClient. The visual Agent Builder canvas is unaffected either way: its node palette (Start, Agent, Note, File search, Guardrails, MCP, If/else, While, Human approval, Transform, Set state) has no code node, so a no-code builder's only code-execution surface is the fixed Code Interpreter container, which also discards all its data 20 minutes after last use.", + shortValue: 'Agents SDK sandbox image only; Code Interpreter is fixed', + confidence: 'verified', + sources: [ + { + url: 'https://developers.openai.com/api/docs/guides/agents/sandboxes', + label: 'Sandbox agents | OpenAI API', + asOf: '2026-08-10', + }, + { + url: 'https://developers.openai.com/api/docs/guides/tools-code-interpreter', + label: 'Code Interpreter | OpenAI API', + asOf: '2026-08-10', + }, + { + url: 'https://developers.openai.com/api/docs/guides/node-reference', + label: 'Node reference | OpenAI API', + asOf: '2026-08-10', + }, + ], + }, apiPublishing: { value: 'Yes: agents/workflows are consumed via the OpenAI API and can be embedded via ChatKit; Agent Builder itself is not a customer-facing REST API generator', @@ -1011,6 +1036,31 @@ export const openaiAgentkitProfile: CompetitorProfile = { }, ], }, + sessionPolicy: { + value: + "Not publicly documented: OpenAI does not document an admin-configurable session lifetime or inactivity timeout for ChatGPT workspaces or the API Platform. The workspace identity controls it does document are SSO/SAML, domain verification, SCIM provisioning, MFA enforcement through the identity provider, and RBAC, so how often members must re-authenticate is set at the upstream IdP rather than by a policy in OpenAI's admin console.", + detail: + "OpenAI's admin rollout guide and Work admin FAQ enumerate identity, access-governance, and compliance controls without a session-duration or idle-timeout setting, and the Codex authentication documentation describes tokens being refreshed automatically during active use ('Codex refreshes tokens automatically during use before they expire, so active sessions usually continue without requiring another browser login') rather than an absolute cap an admin can shorten. No session policy specific to AgentKit or Agent Builder is published.", + shortValue: 'No documented admin session lifetime or idle timeout', + confidence: 'estimated', + sources: [ + { + url: 'https://learn.chatgpt.com/docs/enterprise/admin-setup', + label: 'Admin rollout guide | ChatGPT Learn', + asOf: '2026-08-10', + }, + { + url: 'https://learn.chatgpt.com/docs/enterprise/work-admin-faq', + label: 'ChatGPT Work admin FAQ | ChatGPT Learn', + asOf: '2026-08-10', + }, + { + url: 'https://learn.chatgpt.com/docs/auth', + label: 'Authentication | ChatGPT Learn', + asOf: '2026-08-10', + }, + ], + }, thirdPartyVetting: { value: "Partial: pre-built Connector Registry entries (Dropbox, Google Drive, SharePoint, Teams) and the ChatGPT Apps directory go through OpenAI identity verification and app review, but Agent Builder's MCP node and the Agents SDK can connect to any third-party MCP server with no vendor vetting pipeline documented", diff --git a/apps/sim/lib/compare/data/competitors/openclaw.ts b/apps/sim/lib/compare/data/competitors/openclaw.ts index 86a25169eef..ad3b531b36b 100644 --- a/apps/sim/lib/compare/data/competitors/openclaw.ts +++ b/apps/sim/lib/compare/data/competitors/openclaw.ts @@ -686,6 +686,26 @@ export const openClawProfile: CompetitorProfile = { }, ], }, + codeSandboxRuntime: { + value: + 'Yes: the Docker sandbox the agent executes in is operator-defined. The image is selected via `agents.defaults.sandbox.docker.image` (defaulting to `openclaw-sandbox:bookworm-slim`, which preinstalls bash, ca-certificates, curl, git, jq, python3, and ripgrep but no Node, with the `openclaw-sandbox-common:bookworm-slim` variant layered on top of it adding Node 24 and pnpm), a custom image can be baked from the shipped sandbox build scripts (`scripts/sandbox-setup.sh`, or `scripts/docker/sandbox/Dockerfile.common` for the common variant), and `agents.defaults.sandbox.docker.setupCommand` runs once after container creation to install additional runtimes or CLIs. This is available only because OpenClaw is self-hosted; there is no OpenClaw-operated managed runtime to configure.', + detail: + 'Runtime installation via `setupCommand` requires relaxing three hardening defaults for the setup phase: `docker.network` defaults to `"none"` (no egress, so package managers fail), `readOnlyRoot` defaults to true, and the default image runs as a non-root `sandbox` user. Sandbox exec does not inherit the host `process.env`, so keys and paths for anything installed that way have to come from `agents.defaults.sandbox.docker.env` or from a custom image; the docs note that `docker.env` values are readable via `docker inspect`. Separately, the gateway container image itself (not the sandbox image) accepts build-time `OPENCLAW_IMAGE_APT_PACKAGES` / `OPENCLAW_IMAGE_PIP_PACKAGES` and an `OPENCLAW_HOME_VOLUME` for persisting `/home/node`.', + shortValue: 'Yes: custom sandbox image plus a post-create setupCommand', + confidence: 'verified', + sources: [ + { + url: 'https://docs.openclaw.ai/gateway/sandboxing', + label: 'OpenClaw Docs: Sandboxing', + asOf: '2026-08-10', + }, + { + url: 'https://docs.openclaw.ai/install/docker', + label: 'OpenClaw Docs: Docker install', + asOf: '2026-08-10', + }, + ], + }, apiPublishing: { value: 'Yes, via the official Webhooks plugin: it adds authenticated inbound HTTP routes on the Gateway so external systems (Zapier, n8n, a CI job, or an internal service) can POST JSON to a configured path to create, drive, and manage OpenClaw TaskFlows, the closest OpenClaw feature to publishing a callable REST/webhook endpoint.', @@ -959,6 +979,26 @@ export const openClawProfile: CompetitorProfile = { }, ], }, + sessionPolicy: { + value: + 'Not applicable: there is no signed-in session to bound. The Gateway authenticates callers with a static shared secret (`gateway.auth` token or password, or a trusted-proxy header mode), and the security docs document no session expiry, idle timeout, or time-bound signed session; every authenticated caller holds operator-level access until the secret is rotated.', + detail: + 'The `session.reset` settings that do exist govern conversation context, not authentication: `session.reset.mode` of `"daily"` (`atHour`, default 4) or `"idle"` (`idleMinutes`) starts a fresh chat session, and cron jobs get a fresh conversation session per run. The docs state `sessionKey` is "a routing selector, not an authorization token," and recommend separate Gateway instances per trust boundary rather than session controls inside one shared instance.', + shortValue: 'No signed-in session: static shared-secret operator auth', + confidence: 'verified', + sources: [ + { + url: 'https://docs.openclaw.ai/gateway/security', + label: 'OpenClaw Docs: Security', + asOf: '2026-08-10', + }, + { + url: 'https://docs.openclaw.ai/concepts/session', + label: 'OpenClaw Docs: Session management', + asOf: '2026-08-10', + }, + ], + }, thirdPartyVetting: { value: "No: researchers documented 283 ClawHub skills (about 7.1% of the registry) leaking API keys and other credentials, plus a separate scan finding 24 accounts distributing over 600 malicious skills before scanning existed, roughly 900 skills total with a documented credential-leak or malware finding. That is a direct consequence of ClawHub's structure: it is an open marketplace where any third-party developer can publish, and any user can install, an executable Markdown/code Skill package, not a first-party catalog authored and code-reviewed by OpenClaw itself. This is the opposite trust boundary from Sim, where all 302 blocks are first-party authored and code-reviewed through the standard pull-request process, with no public marketplace for installing arbitrary third-party executable code.", diff --git a/apps/sim/lib/compare/data/competitors/pipedream.ts b/apps/sim/lib/compare/data/competitors/pipedream.ts index 9d938eaa30f..ebfce7c7a49 100644 --- a/apps/sim/lib/compare/data/competitors/pipedream.ts +++ b/apps/sim/lib/compare/data/competitors/pipedream.ts @@ -573,6 +573,36 @@ export const pipedreamProfile: CompetitorProfile = { { url: 'https://pipedream.com/docs', label: 'Pipedream Docs', asOf: '2026-07-02' }, ], }, + codeSandboxRuntime: { + value: + 'Partial: at the package layer only. A code step declares its own third-party dependencies inline, any npm package in Node.js (`import axios from "axios@0.19.2"` pins an exact version, and `^`/`~` ranges are accepted) and any PyPI package in Python (`import requests`, with `# pipedream add-package pandas==2.0.0` to pin), with no package.json or requirements.txt to maintain. The OS layer underneath is not user-configurable — there is no custom image, Dockerfile, or apt-level control: Bash steps ship a Pipedream-chosen set of binaries (curl, jq, git), and the docs state that packages needing binaries or system libraries absent from the execution environment are unsupported.', + detail: + 'Pipedream\'s docs are explicit that workflows start with no packages installed and that importing a module is what makes it available for that step, so the dependency set is genuinely user-controlled per step rather than a vendor-curated allowlist. System-level configuration is not exposed: Pipedream\'s Python docs say of packages requiring environment binaries that "we cannot support these types of packages at this time," and the Bash docs direct users who need a package preinstalled to file a support request, with downloading and building software into the 2GB `/tmp` scratch directory at run time as the only self-service workaround. There is no custom-image, Dockerfile, or apt-level configuration, and because Pipedream is cloud-hosted only there is no self-hosted runtime a team could rebuild instead.', + shortValue: 'Packages only: any npm or PyPI dependency, fixed OS image', + confidence: 'verified', + sources: [ + { + url: 'https://pipedream.com/docs/workflows/building-workflows/code/nodejs', + label: 'Pipedream Docs: Running Node.js in Workflows (npm packages)', + asOf: '2026-08-10', + }, + { + url: 'https://pipedream.com/docs/workflows/building-workflows/code/python', + label: 'Pipedream Docs: Running Python in Workflows (PyPI packages)', + asOf: '2026-08-10', + }, + { + url: 'https://pipedream.com/docs/workflows/building-workflows/code/bash/', + label: 'Pipedream Docs: Running Bash in Workflows (preinstalled binaries)', + asOf: '2026-08-10', + }, + { + url: 'https://pipedream.com/docs/workflows/limits/', + label: 'Pipedream Docs: Limits (2GB `/tmp` disk)', + asOf: '2026-08-10', + }, + ], + }, apiPublishing: { value: 'Yes: workflows can be hosted as HTTP/REST endpoints', detail: @@ -875,6 +905,41 @@ export const pipedreamProfile: CompetitorProfile = { }, ], }, + sessionPolicy: { + value: + "Not publicly documented: Pipedream's workspace administration and SSO documentation enumerates the security controls available to admins — requiring two-factor authentication for all members, configuring SAML/Google/Okta SSO, SCIM provisioning, and managing verified domains, all on the Business plan — and includes no absolute session lifetime, idle timeout, or forced re-authentication interval. Pipedream also does not publish a fixed session length for the dashboard, so the absence of an admin control is inferred from the documentation rather than stated by Pipedream.", + detail: + "Neither the workspace administration docs, the SSO overview, nor the Privacy and Security page mentions session duration, idle timeout, or re-authentication frequency; the only session-related announcement Pipedream has published was a one-time invalidation of all login sessions during a September 2021 maintenance window, which stated no ongoing policy. Workspaces on SSO inherit whatever re-authentication cadence the upstream identity provider enforces, but that is the IdP's policy rather than a Pipedream-side control. The one expiration Pipedream does publish covers API credentials rather than signed-in user sessions: REST API OAuth access tokens expire after 1 hour.", + shortValue: 'No documented admin session lifetime or idle timeout', + confidence: 'estimated', + sources: [ + { + url: 'https://pipedream.com/docs/workflows/workspaces/', + label: 'Pipedream Docs: Managing workspaces (2FA, SSO, verified domains)', + asOf: '2026-08-10', + }, + { + url: 'https://pipedream.com/docs/workflows/workspaces/sso/', + label: 'Pipedream Docs: Single Sign-On Overview', + asOf: '2026-08-10', + }, + { + url: 'https://pipedream.com/docs/privacy-and-security/', + label: 'Pipedream Docs: Privacy and Security', + asOf: '2026-08-10', + }, + { + url: 'https://pipedream.com/community/t/update-to-pipedream-login-session-handling-on-monday-september-6th/1174', + label: 'Pipedream Community: Update to login session handling', + asOf: '2026-08-10', + }, + { + url: 'https://pipedream.com/docs/rest-api/auth', + label: 'Pipedream Docs: REST API Authentication (1-hour access tokens)', + asOf: '2026-08-10', + }, + ], + }, thirdPartyVetting: { value: "No: Pipedream's 3,000+ app integrations are backed by a public component registry (pipedreamhq/pipedream on GitHub) where any developer can fork the repo, write a trigger or action, and submit it as a pull request for anyone else's workflows to run; users can also write and execute their own arbitrary custom code steps.", diff --git a/apps/sim/lib/compare/data/competitors/power-automate.ts b/apps/sim/lib/compare/data/competitors/power-automate.ts index 0d280672d7b..dc080a88d1d 100644 --- a/apps/sim/lib/compare/data/competitors/power-automate.ts +++ b/apps/sim/lib/compare/data/competitors/power-automate.ts @@ -749,6 +749,42 @@ export const powerAutomateProfile: CompetitorProfile = { }, ], }, + codeSandboxRuntime: { + value: + 'No: the code surface Power Platform exposes runs on a fixed, Microsoft-curated runtime. Custom connector code is C# against .NET Standard 2.0, and Microsoft states the environment is closed — "Not all C# namespaces are supported. Currently, you can use functions from the following namespaces only" — with one script file per connector, capped at 1 MB, and no mechanism to declare third-party packages or system packages. Microsoft\'s developer guidance routes custom server-side logic out of the product instead, to custom connectors and Azure Functions ("Build Azure Functions: Craft Azure Functions to extend apps with custom server-side logic"), whose dependencies are managed in Azure; an Office Script invoked through the Excel Online (Business) "Run script" action likewise runs in the Office Scripts runtime. The scripting actions in Power Automate for desktop do accept externally supplied dependencies (the Run Python script action takes "Module folder paths", documented as "the paths of folders where external Python modules lie", and Run .NET script takes a "References to be loaded" root path for .dll files), but the Python version is limited to a choice of 2.7 or 3.4, dependencies must be pre-staged on disk rather than declared as a package manifest, and those actions run on a customer-managed Windows machine rather than in a managed cloud runtime.', + detail: + 'Power Automate for desktop also supports environment-level custom actions: an organization uploads signed .dll files plus their dependency .dll files as a .cab package, capped at 30 MB per custom action group, and all dependencies used in custom actions must be the same version as those in Power Automate for desktop itself. That is assembly-level extension of a locally installed runtime rather than a declarative package/system-package manifest for a hosted sandbox. Microsoft states the constraint affirmatively for the in-product code surface rather than merely omitting the feature: the supported namespace list for custom connector code is enumerated and closed, and the supported .NET version is pinned to .NET Standard 2.0.', + shortValue: 'No configurable sandbox; desktop scripts run on customer machines', + confidence: 'verified', + sources: [ + { + url: 'https://learn.microsoft.com/en-us/power-automate/desktop-flows/actions-reference/scripting', + label: 'Scripting actions reference - Power Automate | Microsoft Learn', + asOf: '2026-08-10', + }, + { + url: 'https://learn.microsoft.com/en-us/power-automate/desktop-flows/custom-actions', + label: 'Custom actions - Power Automate | Microsoft Learn', + asOf: '2026-08-10', + }, + { + url: 'https://learn.microsoft.com/en-us/office/dev/scripts/develop/power-automate-integration', + label: 'Run Office Scripts with Power Automate - Office Scripts | Microsoft Learn', + asOf: '2026-08-10', + }, + { + url: 'https://learn.microsoft.com/en-us/connectors/custom-connectors/write-code', + label: 'Write code in a custom connector | Microsoft Learn', + asOf: '2026-08-10', + }, + { + url: 'https://learn.microsoft.com/en-us/power-automate/developer/dev-enterprise-intro', + label: + 'Power Automate for enterprise developers, ISVs, and partners - Power Automate | Microsoft Learn', + asOf: '2026-08-10', + }, + ], + }, apiPublishing: { value: 'Flows can be triggered via HTTP Request triggers (effectively exposing a flow as a callable webhook/API endpoint); Dataverse/Power Platform also expose Web API endpoints for programmatic access', @@ -1062,6 +1098,28 @@ export const powerAutomateProfile: CompetitorProfile = { }, ], }, + sessionPolicy: { + value: + 'Partial: an admin can turn on Session Expiration per environment from the Power Platform admin center (Settings > Product > Privacy + Security) and set a maximum session length between 60 and 1,440 minutes (24 hours) plus a timeout warning of at least 20 minutes, and separately turn on an Inactivity timeout from a minimum of 5 minutes up to less than the session length. Both apply to all users in the environment and override the default Microsoft Entra ID session policy, which itself is admin-configurable through Conditional Access sign-in frequency (default a rolling 90-day window, requiring an Entra ID P1 or P2 license). The qualifier is scope: Microsoft frames these settings as protecting "customer engagement apps, such as Dynamics 365 Sales, Dynamics 365 Customer Service" and Dataverse, and names first-party surfaces that do not enforce them; enforcement for the Power Automate maker portal itself is not documented on that page.', + detail: + 'Microsoft documents these settings for Dataverse and the customer engagement apps, and lists surfaces that do not enforce them, including Power Apps canvas apps, Dynamics 365 for Outlook, and the Dynamics 365 phone and tablet apps. Changed values take effect the next time a user signs in; session timeout is enforced server-side while inactivity timeout is a client-side sign-out.', + shortValue: 'Per-environment timeouts, documented for Dataverse and Dynamics 365 apps', + confidence: 'verified', + sources: [ + { + url: 'https://learn.microsoft.com/en-us/power-platform/admin/user-session-management', + label: + 'Security enhancements for user sessions and access management - Power Platform | Microsoft Learn', + asOf: '2026-08-10', + }, + { + url: 'https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-session-lifetime', + label: + 'Conditional Access adaptive session lifetime policies - Microsoft Entra ID | Microsoft Learn', + asOf: '2026-08-10', + }, + ], + }, thirdPartyVetting: { value: "Partial: the certified connector catalog (1,400+ connectors, including third-party 'Independent Publisher' submissions) goes through a Microsoft Certification team review, identity/credential verification of the publisher, and swagger/endpoint/security validation before being listed. But any user or org can also build and share 'custom connectors' that call arbitrary APIs, bypassing the certification catalog entirely with no Microsoft security review. Zenity's security research found custom connectors can reach connectors otherwise blocked by Data Loss Prevention (DLP) policies, a documented DLP-bypass tied to the custom-connector path specifically.", diff --git a/apps/sim/lib/compare/data/competitors/retool.ts b/apps/sim/lib/compare/data/competitors/retool.ts index c64c5a8e7c5..7018b673566 100644 --- a/apps/sim/lib/compare/data/competitors/retool.ts +++ b/apps/sim/lib/compare/data/competitors/retool.ts @@ -650,6 +650,31 @@ export const retoolProfile: CompetitorProfile = { confidence: 'unknown', sources: [], }, + codeSandboxRuntime: { + value: + 'Partial: the dependency set of a workflow Code block is user-configurable, but only at the package layer. In the workflow editor\'s Libraries tab, "Add Python library" picks from Retool\'s built-in library set, and "Modify requirements.txt" declares an arbitrary list of public PyPI packages with pinned versions; the JavaScript equivalent adds public npm packages via "Modify package.json". Package-level configuration only: there is no documented way to declare OS-level system packages or preinstalled CLI binaries for the runtime.', + detail: + 'Beyond the preloaded set (Lodash, Moment.js, UUID, Numbro, and PapaParse are the JavaScript libraries Retool documents by name; the Python built-in set is not enumerated in the docs, which describe "built-in support for many popular libraries" and expose the list only through an interactive browser), builders add their own dependencies per workflow. Private npm/PyPI registries are self-hosted only and require a configured code-executor service, the container that runs user-defined JavaScript and Python with installed custom libraries; Retool sandboxes environment creation with NsJail, which needs privileged container access, and self-hosted operators can disable that sandboxing entirely with CONTAINER_UNPRIVILEGED_MODE.', + shortValue: 'Packages only: per-workflow PyPI and npm libraries', + confidence: 'verified', + sources: [ + { + url: 'https://docs.retool.com/workflows/guides/blocks/python', + label: 'Execute Python with the Code block | Retool Docs', + asOf: '2026-08-10', + }, + { + url: 'https://docs.retool.com/workflows/guides/blocks/javascript', + label: 'Execute JavaScript with the Code block | Retool Docs', + asOf: '2026-08-10', + }, + { + url: 'https://docs.retool.com/self-hosted/reference/environment-variables', + label: 'Environment variables reference | Retool Docs', + asOf: '2026-08-10', + }, + ], + }, apiPublishing: { value: 'Enterprise plan includes "platform APIs" for managing/orchestrating Retool resources; Retool itself can also be exposed as an MCP server for programmatic/agent access.', @@ -935,6 +960,32 @@ export const retoolProfile: CompetitorProfile = { }, ], }, + sessionPolicy: { + value: + 'Partial: an absolute session lifetime cap is configurable, but the cloud control is coarse and lives inside SSO settings. Toggling "Use short session" in the organization\'s Single Sign On settings drops the session length from one week to 12 hours. Self-hosted deployments get finer control through SESSION_DURATION_MINUTES, which sets an arbitrary custom session duration in minutes (default 10080, or 720 when USE_SHORT_SESSIONS is true). No inactivity or idle timeout is documented.', + detail: + "The documented policy is an absolute cap measured from sign-in, not an idle timer, so an active or idle browser session persists until the cap expires. Cloud orgs choose between the two fixed values (one week or 12 hours); only self-hosted operators can specify a duration of their own. Retool's pricing page lists Custom SSO (SAML/OpenID) under Enterprise and does not list Google SSO at any tier, and Retool's documentation does not state which plans can reach the short-session toggle. A Retool staff member states on the community forum that configuring Google SSO, which exposes the same short-session control, does not require the Enterprise plan; that is not confirmed in Retool's official documentation.", + shortValue: 'Absolute cap only, coarse on cloud; no idle timeout', + confidence: 'estimated', + sources: [ + { + url: 'https://docs.retool.com/sso/guides/authentication/short-session', + label: 'Configure SSO session duration | Retool Docs', + asOf: '2026-08-10', + }, + { + url: 'https://community.retool.com/t/sso-on-business-plan/66979', + label: 'SSO on business plan | Retool Community', + asOf: '2026-08-10', + }, + { + url: 'https://docs.retool.com/self-hosted/reference/environment-variables', + label: 'Environment variables reference | Retool Docs', + asOf: '2026-08-10', + }, + { url: 'https://retool.com/pricing', label: 'Retool Pricing', asOf: '2026-08-10' }, + ], + }, thirdPartyVetting: { value: "Yes: Retool's built-in integrations (Resources) are a first-party catalog of roughly 90+ databases, APIs, AI services, and cloud tools built and maintained by Retool, not an open marketplace of third-party-submitted connectors. Custom Component Libraries let a customer's own developers pull in npm packages to build custom UI components, but these are private to the authoring organization by default, not a shared registry of code from unrelated third parties.", diff --git a/apps/sim/lib/compare/data/competitors/stackai.ts b/apps/sim/lib/compare/data/competitors/stackai.ts index 00a2b46fa57..31f4adff439 100644 --- a/apps/sim/lib/compare/data/competitors/stackai.ts +++ b/apps/sim/lib/compare/data/competitors/stackai.ts @@ -592,6 +592,31 @@ export const stackaiProfile: CompetitorProfile = { }, ], }, + codeSandboxRuntime: { + value: + 'Partial: at the package layer only. The newer Code Node exposes a Dependencies field, documented as "a list of package names that get installed into the sandbox before your code runs," so builders declare third-party Python/TypeScript packages per node. The deprecated Python Code node it replaces is a fixed image restricted to a vendor-curated set of pre-imported libraries.', + detail: + 'Code Node runs in an isolated sandbox with /home/user as the working directory; StackAI\'s docs contrast it with the Python Code node as "Allows importing custom libraries" versus "Restricted to pre-imported libraries." That older node\'s fixed set covers pandas, numpy, requests, BeautifulSoup, matplotlib, plotly, pypdf, sklearn, tiktoken, and weaviate among others, with no way to add to it. Dependency declaration is package-level only — StackAI does not document declaring OS-level system packages or preinstalled CLI binaries, and dependencies add sandbox startup time. Sandbox isolation is provided by E2B, which runs each execution as an isolated VM.', + shortValue: 'Packages only: per-node dependencies on the Code Node', + confidence: 'verified', + sources: [ + { + url: 'https://docs.stackai.com/workflow-builder/utils-logic-and-others/logic/code-node', + label: 'Code Node (Dependencies field) - StackAI Docs', + asOf: '2026-08-10', + }, + { + url: 'https://docs.stackai.com/workflow-builder/utils-logic-and-others/logic/python-code', + label: 'Python Code node pre-imported libraries - StackAI Docs', + asOf: '2026-08-10', + }, + { + url: 'https://www.e2b.dev/blog/stackai', + label: 'How StackAI Runs Enterprise AI Agents - E2B blog', + asOf: '2026-08-10', + }, + ], + }, apiPublishing: { value: 'Yes: workflows publishable as a REST API with generated client snippets', detail: @@ -819,6 +844,31 @@ export const stackaiProfile: CompetitorProfile = { }, ], }, + sessionPolicy: { + value: + "Not publicly documented: no admin-configurable session lifetime or idle timeout appears in StackAI's public documentation. Its Authentication and MFA page covers password login, org-wide MFA enforcement, and SSO, and the Feature Access page enumerating org-level admin settings (MFA, LLM access, app/tool availability, knowledge bases, advanced features) lists no session control.", + detail: + "Where SSO is used, StackAI states MFA enforcement happens at the identity provider, so an organization's effective re-authentication cadence is inherited from its upstream IdP rather than set in StackAI. No fixed session length is published either, and the Trust Center lists access-control and termination policies without any session-timeout control.", + shortValue: 'Not publicly documented', + confidence: 'estimated', + sources: [ + { + url: 'https://docs.stackai.com/welcome-to-stackai/security-and-governance/security-in-stackai/authentication-and-mfa', + label: 'Authentication and MFA - StackAI Docs', + asOf: '2026-08-10', + }, + { + url: 'https://docs.stackai.com/welcome-to-stackai/security-and-governance/security-in-stackai/feature-access', + label: 'Feature Access (org-level admin settings) - StackAI Docs', + asOf: '2026-08-10', + }, + { + url: 'https://trust.stackai.com/', + label: 'StackAI Trust Center', + asOf: '2026-08-10', + }, + ], + }, thirdPartyVetting: { value: "Yes: StackAI's 70+ app integrations (databases, cloud storage, CRMs, communication tools) are built and maintained by StackAI's own team, not an open community marketplace. Users needing an unlisted service fall back to a built-in Custom API node or connect their own MCP servers, rather than installing code published by other third-party users.", diff --git a/apps/sim/lib/compare/data/competitors/tines.ts b/apps/sim/lib/compare/data/competitors/tines.ts index 4b095cb920f..1440063c07c 100644 --- a/apps/sim/lib/compare/data/competitors/tines.ts +++ b/apps/sim/lib/compare/data/competitors/tines.ts @@ -635,10 +635,15 @@ export const tinesProfile: CompetitorProfile = { }, customCodeSteps: { value: - 'No general-purpose custom-code action. Logic is expressed via built-in "Formulas"/functions and HTTP Request actions rather than a Python/JS code node', - shortValue: 'No general-purpose code step; Formulas and HTTP actions', - confidence: 'estimated', + 'Yes: the Run Script action executes builder-authored code inline in a workflow (the script must define a `main` function), running in AWS Lambda in the same region as the tenant. It is currently limited to the `python3.13` runtime, so there is no JavaScript or other-language option. Lighter-weight logic is also expressible via built-in "Formulas"/functions without a code action.', + shortValue: 'Yes: Run Script action, Python only', + confidence: 'verified', sources: [ + { + url: 'https://www.tines.com/docs/actions/tools/run-script/', + label: 'Run script | Docs | Tines', + asOf: '2026-08-10', + }, { url: 'https://www.tines.com/docs/formulas/functions/', label: 'Functions docs', @@ -646,6 +651,26 @@ export const tinesProfile: CompetitorProfile = { }, ], }, + codeSandboxRuntime: { + value: + 'Yes: the Run Script action exposes a Requirements field where builders declare PyPI dependencies "in the format of a requirements.txt file with each requirement separated by a new line" (e.g. numpy==1.25), built at runtime as AWS Lambda layers with a 250MB unzipped package limit. Tines also supports custom runtimes, user-built runtime archives that bundle specific package versions, system libraries, custom Python builds, and extra files such as certificates or config files.', + detail: + 'The runtime is limited to Python (python3.13 on the managed Lambda path); there is no Node/other-language option. Custom runtimes must be built on Amazon Linux 2023 to match Lambda, and are scoped either to Cloud (Lambda) or to Docker, meaning the Tines command runner reached over a tunnel for self-hosted execution. Timeout (10s default, 110s max) and networking mode (Standard, Dedicated, or No networking) are configurable per action.', + shortValue: 'Yes: requirements.txt deps plus custom runtimes', + confidence: 'verified', + sources: [ + { + url: 'https://www.tines.com/docs/actions/tools/run-script/', + label: 'Run script | Docs | Tines', + asOf: '2026-08-10', + }, + { + url: 'https://www.tines.com/docs/actions/tools/run-script/custom-runtimes/', + label: 'Custom runtimes | Docs | Tines', + asOf: '2026-08-10', + }, + ], + }, apiPublishing: { value: 'Yes: "Workflows as APIs": a Story can be exposed via Send-to-Story so external callers can invoke it synchronously and optionally wait for a response', @@ -917,6 +942,26 @@ export const tinesProfile: CompetitorProfile = { }, ], }, + sessionPolicy: { + value: + 'Yes: Tines states it "supports the ability for administrators to set a custom session timeout length to adhere to your organization\'s policies." Users are automatically logged out of the Tines UI after a period of inactivity, defaulting to 1 day.', + detail: + 'The documented control is an inactivity timeout with an admin-set length; Tines does not publish a separate absolute session lifetime cap measured from sign-in, nor the permitted range of timeout values or any plan gating on the setting.', + shortValue: 'Yes: admin-set session timeout, 1 day default', + confidence: 'verified', + sources: [ + { + url: 'https://www.tines.com/security/', + label: 'Security at Tines', + asOf: '2026-08-10', + }, + { + url: 'https://www.tines.com/tines-security-best-practices/', + label: 'Tines security best practices', + asOf: '2026-08-10', + }, + ], + }, thirdPartyVetting: { value: "Yes: Tines' executable actions (HTTP Request, webhooks, email, Send to Story, AI Agent, etc.) are a fixed, first-party set built and maintained by Tines, not a plugin/node marketplace. Third-party integrations go through the generic HTTP Request action against that tool's API, or by importing a pre-built 'Story' (a workflow template/JSON config, not installable code) from the community Story Library. No mechanism lets a third party publish executable custom actions/nodes that other tenants install.", diff --git a/apps/sim/lib/compare/data/competitors/vellum.ts b/apps/sim/lib/compare/data/competitors/vellum.ts index 8a703b698b3..1b9046b0dfc 100644 --- a/apps/sim/lib/compare/data/competitors/vellum.ts +++ b/apps/sim/lib/compare/data/competitors/vellum.ts @@ -607,6 +607,38 @@ export const vellumProfile: CompetitorProfile = { }, ], }, + codeSandboxRuntime: { + value: + "Yes: Code Execution Nodes run against a user-configurable environment. Public PyPI and npm packages can be declared as dependencies, package dependencies can be defined once at the Workflow level through the Workflow Settings modal (which generates a reusable container image) instead of per node, private Python and AWS CodeArtifact repositories are supported, and a fully custom Docker image can be built and pushed with the 'vellum image push' CLI command to install system-level dependencies and pre-defined application code.", + detail: + "Vellum's launch post for the feature describes custom container images as giving 'full control over their runtime, so you can install system-level dependencies, rely on private packages, and reference pre-defined application code'; the documentation itself puts it more narrowly, saying the images let you 'use pre-existing logic from the rest of your repository, or some bespoke binaries', and requires that they inherit from the vellumai/python-workflow-runtime base image. Images must be built for linux/amd64 and each instance is capped at 2048MB (2GB) of memory, with higher limits available by contacting support. The docs do not state a plan-tier restriction and do not address self-hosted availability.", + shortValue: 'PyPI/npm deps, private repos, and custom Docker images', + confidence: 'verified', + sources: [ + { + url: 'https://docs.vellum.ai/developers/workflows-sdk/custom-container-images', + label: 'Custom Docker Images - Vellum Documentation', + asOf: '2026-08-10', + }, + { + url: 'https://docs.vellum.ai/changelog/2025/2025-07', + label: + 'Vellum Changelog, July 2025 (workflow-level package dependencies, private package repositories)', + asOf: '2026-08-10', + }, + { + url: 'https://www.vellum.ai/blog/introducing-custom-docker-images-custom-nodes', + label: 'Introducing Custom Docker Images & Custom Nodes - Vellum Blog', + asOf: '2026-08-10', + }, + { + url: 'https://www.vellum.ai/blog/running-arbitrary-code-in-workflows-evals', + label: + 'Running Arbitrary Code in Workflows & Evals - Vellum Blog (PyPI and npm support)', + asOf: '2026-08-10', + }, + ], + }, apiPublishing: { value: 'Deploying a Workflow from the Vellum UI produces a code snippet to call it in production as an API. Vellum handles execution server-side and callers just supply input variables; each execution is also viewable/shareable via an execution URL.', @@ -873,6 +905,31 @@ export const vellumProfile: CompetitorProfile = { confidence: 'unknown', sources: [], }, + sessionPolicy: { + value: + 'Not publicly documented: no admin-configurable session lifetime cap or idle timeout is documented for Vellum workspaces. The docs index lists four security pages (Data Privacy and Storage, HMAC Authentication, RBAC, Static IPs) and two organization-settings pages (Manage Organization Access, Data Retention Policies), none of which describe session length, inactivity expiry, or forced re-authentication; the only admin-configurable access controls documented are workspace roles and domain-based automatic join.', + detail: + 'The Manage Organization Access page covers only domain-based automatic join and the verified-domain list. The Data Privacy and Storage page references RBAC and HMAC authentication for API access but says nothing about interactive session duration. No first-party SAML/OIDC setup page exists either, so an inherited IdP session policy cannot be confirmed as available.', + shortValue: 'No documented session lifetime or idle timeout controls', + confidence: 'estimated', + sources: [ + { + url: 'https://docs.vellum.ai/llms.txt', + label: 'Vellum Documentation index (no session or SSO/SAML page listed)', + asOf: '2026-08-10', + }, + { + url: 'https://docs.vellum.ai/product/organizations/manage-access.md', + label: 'Manage Organization Access - Vellum Documentation', + asOf: '2026-08-10', + }, + { + url: 'https://docs.vellum.ai/product/security/data-privacy-and-storage.md', + label: 'Data Privacy and Storage - Vellum Documentation', + asOf: '2026-08-10', + }, + ], + }, thirdPartyVetting: { value: "Yes: Vellum's tool ecosystem is closed and vendor/partner controlled, not an open marketplace. Its 100+ native integrations are built and maintained by Vellum, its Composio partnership adds access to Composio's curated tool library, and 'Custom Nodes' are authored by the customer's own team for internal reuse rather than published to a shared marketplace for other tenants.", diff --git a/apps/sim/lib/compare/data/competitors/workato.ts b/apps/sim/lib/compare/data/competitors/workato.ts index 71b71548154..2b41a5aae73 100644 --- a/apps/sim/lib/compare/data/competitors/workato.ts +++ b/apps/sim/lib/compare/data/competitors/workato.ts @@ -728,6 +728,31 @@ export const workatoProfile: CompetitorProfile = { }, ], }, + codeSandboxRuntime: { + value: + 'No: every Workato code surface runs on a fixed, Workato-controlled image with a vendor-curated dependency set. The Python snippets connector runs Python 3.9 or later with the standard library plus a published list of preinstalled packages (pandas, NumPy, requests, lxml, openpyxl, pypdf, bcrypt, msoffcrypto, pytz, xlrd among others) and states that user-provided libraries are not supported; the JavaScript snippets connector runs Node.js 20.11.0 with node_fetch, lodash, gRPC, and Google Protobuf preinstalled and carries the same restriction. There is no package-install step, no OS-level package declaration, and no selection of preinstalled CLI binaries.', + detail: + 'The Ruby Connector SDK moved custom connector code into isolated containers in March 2025, which removed the older Ruby method whitelist and gave developers Ruby 2.7 built-in libraries plus a documented set of 14 gems available in the SDK container (jwt, nokogiri, rest-client, aws-sigv4 and others). That widened what the fixed image contains but did not make it configurable: the docs describe no mechanism for a developer to add a gem. Because Workato is SaaS-only with no self-hostable execution engine, there is also no customer-built container image to fall back on.', + shortValue: 'No: fixed images with curated, non-extendable packages', + confidence: 'verified', + sources: [ + { + url: 'https://docs.workato.com/connectors/python.html', + label: 'Python snippets by Workato | Workato Docs', + asOf: '2026-08-10', + }, + { + url: 'https://docs.workato.com/connectors/javascript.html', + label: 'JavaScript snippets by Workato | Workato Docs', + asOf: '2026-08-10', + }, + { + url: 'https://docs.workato.com/developing-connectors/sdk/sdk-reference/whitelist-removal.html', + label: 'Full access to Ruby | Workato Docs', + asOf: '2026-08-10', + }, + ], + }, apiPublishing: { value: 'Yes: Workato supports "API recipes" built on its API Platform, which expose a recipe as a REST API endpoint that external users, other recipes, or integrated systems can call to access and exchange data', @@ -1049,6 +1074,26 @@ export const workatoProfile: CompetitorProfile = { }, ], }, + sessionPolicy: { + value: + 'Yes: a workspace-wide session timeout duration is set by admins under Workspace admin > Settings > Workspace > General, documented as "the time of inactivity after which users are logged out." Workato\'s security FAQs state the default is seven days and the value is configurable from 15 minutes to 14 days.', + detail: + 'This is an inactivity/idle timeout applied across the workspace, not a separate absolute session lifetime cap measured from sign-in; Workato documents no second control for maximum session age. The setting sits in the general workspace admin settings rather than being gated to a specific security add-on in the documentation.', + shortValue: 'Yes: workspace idle timeout, 15 minutes to 14 days', + confidence: 'verified', + sources: [ + { + url: 'https://docs.workato.com/en/workspace-admin-settings.html', + label: 'Workato Docs: Workspace admin settings', + asOf: '2026-08-10', + }, + { + url: 'https://docs.workato.com/security/security-faqs.html', + label: 'Workato Docs: Security FAQs', + asOf: '2026-08-10', + }, + ], + }, thirdPartyVetting: { value: 'Partial: Workato has a large first-party catalog of native, Workato-built connectors, plus an open Community Library where any developer with Connector SDK access can build and publish a connector that other users install, alongside an invite-only Partner Connector tier that does get dedicated Workato code review. This is a genuine public marketplace for third-party executable connector code, unlike a vendor with no such marketplace at all.', diff --git a/apps/sim/lib/compare/data/competitors/zapier.ts b/apps/sim/lib/compare/data/competitors/zapier.ts index 467e179f099..55632637da7 100644 --- a/apps/sim/lib/compare/data/competitors/zapier.ts +++ b/apps/sim/lib/compare/data/competitors/zapier.ts @@ -660,6 +660,21 @@ export const zapierProfile: CompetitorProfile = { }, ], }, + codeSandboxRuntime: { + value: + 'Partial: at the package level only. Code by Zapier lets a builder declare public npm (JavaScript) or PyPI (Python) packages for a Code step from a Packages panel in the editor, optionally pinned to a version, on Professional, Team, and Enterprise plans. There is no control over OS-level system packages or preinstalled CLI binaries, and private registries are not supported.', + detail: + 'The standard Node.js library and fetch are available by default. Zapier documents three constraints on what can be declared: only ESM JavaScript packages work (CommonJS-only packages do not), native modules requiring compiled binaries or system-level access do not work, and installs must finish within 30 seconds (120 seconds on Enterprise) inside a 512 MB memory ceiling on all plans. The Free plan cannot use third-party packages at all.', + shortValue: 'Packages only: public npm/PyPI on paid plans, no OS-level control', + confidence: 'verified', + sources: [ + { + url: 'https://help.zapier.com/hc/en-us/articles/43800622540045-Use-third-party-packages-in-Code-steps', + label: 'Use third-party packages in Code steps', + asOf: '2026-08-10', + }, + ], + }, apiPublishing: { value: 'Unknown', detail: @@ -978,6 +993,28 @@ export const zapierProfile: CompetitorProfile = { }, ], }, + sessionPolicy: { + value: + "No: Zapier's session timeout is a fixed platform default of 7 days that an admin cannot change. The only way to shorten it is indirectly, through SAML SSO: if the identity provider sends a session timeout, Zapier honors it when it is shorter than the 7-day default, and falls back to its own default when it is longer.", + detail: + "Zapier's Enterprise admin tools cover SSO, SCIM, domain capture, managed apps, allowed domains, Zap approvals, usage alerts, and Zap history retention, but document no absolute session-lifetime or idle-timeout control. SAML SSO itself is limited to Team and Enterprise plans.", + shortValue: 'No: fixed 7-day session, shortened only by an IdP', + confidence: 'verified', + sources: [ + { + url: 'https://help.zapier.com/hc/en-us/articles/8496279747085-Set-up-single-sign-on-with-SAML', + label: + 'Set up single sign-on with SAML (7-day default session timeout; IdP wins only if shorter)', + asOf: '2026-08-10', + }, + { + url: 'https://help.zapier.com/hc/en-us/articles/44796621276685-Set-up-admin-tools-for-your-Enterprise-account', + label: + 'Set up admin tools for your Enterprise account (no session-lifetime setting listed)', + asOf: '2026-08-10', + }, + ], + }, thirdPartyVetting: { value: "Partial: Zapier's App Directory is an open developer ecosystem, not a closed first-party catalog. Any developer can build an integration on the Zapier Developer Platform and submit it for public listing. Zapier's review checks publishing/technical requirements (HTTPS-only endpoints, no hardcoded credentials, OAuth verification) rather than a deep security audit, and Zapier tells customers these apps are 'owned and operated by third parties' and that users are responsible for evaluating trust in the developer.", diff --git a/apps/sim/lib/compare/data/feature-catalog.ts b/apps/sim/lib/compare/data/feature-catalog.ts index 2f57db7ba9a..fdaf554dec1 100644 --- a/apps/sim/lib/compare/data/feature-catalog.ts +++ b/apps/sim/lib/compare/data/feature-catalog.ts @@ -182,6 +182,23 @@ export const SIM_FEATURES: SimFeature[] = [ }, ], }, + { + id: 'org-session-policies', + name: 'Organization session policies', + category: 'enterprise-governance', + tags: ['enterprise', 'security'], + description: + 'Enterprise organization owners and admins can cap max session lifetime (1 to 8,760 hours from sign-in, regardless of activity) and set an idle timeout (48 to 8,760 hours without activity), applied to every member on every device. Both limits are optional; the default is a 30-day session that extends automatically while a member stays active. A separate "Sign out all members" action revokes every member session in the organization except the acting admin\'s own.', + competitiveNote: + 'Automation platforms commonly ship SSO without any session-lifetime control of their own, leaving re-authentication cadence entirely to the upstream identity provider.', + sources: [ + { + url: 'https://docs.sim.ai/platform/enterprise/session-policies', + label: 'Sim Docs: Session Policies', + asOf: '2026-08-10', + }, + ], + }, { id: 'scim-directory-sync', name: 'SCIM / automated directory sync', @@ -696,12 +713,29 @@ export const SIM_FEATURES: SimFeature[] = [ category: 'control-flow-execution', tags: [], description: - 'A Function block runs arbitrary code: import-free JavaScript executes in a fast local VM, while JavaScript with imports and all Python execute in a remote E2B sandbox using dedicated templates (including one with python-pptx/docx/openpyxl/reportlab preinstalled for document generation).', + 'A Function block runs arbitrary JavaScript, Python, or Shell. Import-free JavaScript stays in a fast local isolated runtime; JavaScript with imports, all Python, and all Shell run in a remote sandbox provider (E2B or Daytona), defaulting to a dedicated Function base image that ships a data-science stack and generic CLIs such as jq, yq, ripgrep, and sqlite3.', sources: [ { - url: 'https://docs.sim.ai/blocks/function', + url: 'https://docs.sim.ai/workflows/blocks/function', label: 'Sim Docs: Function Block', - asOf: '2026-07-02', + asOf: '2026-08-10', + }, + ], + }, + { + id: 'configurable-workspace-sandboxes', + name: 'Configurable workspace code sandboxes', + category: 'control-flow-execution', + tags: ['enterprise'], + description: + 'A workspace maintains named sandboxes, each declaring a language, its pip or npm dependencies, optional Debian/APT system packages, and optional managed CLI tools from a catalog grouped by cloud, Kubernetes, infrastructure, deployment, data and storage, and security tools. A Function block selects one and its code can import those dependencies and run those commands. Only workspace admins can create or edit them, and on sim.ai they require an active Max or Enterprise plan. There, each specification is prebuilt into a reusable image so runs pay no install cost, and identical specifications share one build; a self-hosted deployment using Daytona installs the specification at the start of every run instead, since prebuilt images require E2B. Managed CLIs use pinned, integrity-checked vendor artifacts.', + competitiveNote: + 'Most automation platforms run custom code on a fixed image whose dependency set the vendor controls, so an unlisted package or vendor CLI is simply unavailable without leaving the platform.', + sources: [ + { + url: 'https://docs.sim.ai/workflows/blocks/function#sandboxes', + label: 'Sim Docs: Function block - Sandboxes', + asOf: '2026-08-10', }, ], }, diff --git a/apps/sim/lib/compare/data/sim.ts b/apps/sim/lib/compare/data/sim.ts index 91dba4972d4..0aadd0a9ba3 100644 --- a/apps/sim/lib/compare/data/sim.ts +++ b/apps/sim/lib/compare/data/sim.ts @@ -682,6 +682,26 @@ export const simProfile: CompetitorProfile = { }, ], }, + codeSandboxRuntime: { + value: + 'Yes: named sandboxes a workspace maintains and a Function block selects, each declaring a language, its pip or npm dependencies, optional Debian/APT system packages, and optional managed CLI tools from a catalog grouped by cloud, Kubernetes, infrastructure, deployment, data and storage, and security tools; on sim.ai they require an active Max or Enterprise plan', + detail: + 'Only workspace admins can create or edit sandboxes, in Settings → Sandboxes. On sim.ai each specification is prebuilt into a reusable image so runs pay no install cost; a self-hosted deployment using Daytona installs the dependencies, system packages, and managed CLI tools inside the sandbox at the start of every run instead, and prebuilt images require E2B. Two sandboxes with the same language, dependency list, system packages, and managed CLI tools share one build. Every managed CLI entry uses a pinned, integrity-checked vendor artifact. Self-hosted deployments turn sandboxes on with SANDBOXES_ENABLED, and additionally need a remote execution provider and a dedicated Function base image configured. With no sandbox selected, remote code runs on the dedicated Function base; import-free JavaScript stays in the local isolated runtime and ignores the sandbox selection either way.', + shortValue: 'Named sandboxes: packages, system packages, managed CLIs', + confidence: 'verified', + sources: [ + { + url: 'https://docs.sim.ai/workflows/blocks/function#sandboxes', + label: 'Sim Docs: Function block - Sandboxes', + asOf: '2026-08-10', + }, + { + url: 'https://docs.sim.ai/platform/enterprise/self-hosted', + label: 'Sim Docs: Self-hosted enterprise', + asOf: '2026-08-10', + }, + ], + }, apiPublishing: { value: 'Yes: a public REST API (mostly under /api/, with /api/v1 reserved for logs and audit-log endpoints) supporting API-triggered workflow execution and deployment rollback', @@ -999,6 +1019,21 @@ export const simProfile: CompetitorProfile = { }, ], }, + sessionPolicy: { + value: + 'Yes: Enterprise organization owners and admins can set a max session lifetime (1 to 8,760 hours from sign-in, regardless of activity) and an idle timeout (48 to 8,760 hours without activity), applied to every member on every device', + detail: + 'Both limits are optional; leaving them empty keeps the default of 30-day sessions that extend automatically while a member stays active. A separate "Sign out all members" action immediately revokes every member session in the organization except the admin\'s own, for use after a security incident or an offboarding wave. The 48-hour idle floor exists because session activity is recorded at most once per day, so a shorter window could sign out members who are actively working.', + shortValue: 'Max session lifetime and idle timeout, applied org-wide', + confidence: 'verified', + sources: [ + { + url: 'https://docs.sim.ai/platform/enterprise/session-policies', + label: 'Sim Docs: Session Policies', + asOf: '2026-08-10', + }, + ], + }, thirdPartyVetting: { value: "Yes: every one of Sim's 266 blocks is first-party authored and code-reviewed through the standard pull-request process in the main Sim repository; there is no public marketplace where an arbitrary third party can publish and have other users install executable tool code without going through Sim's own review", @@ -1106,21 +1141,21 @@ export const simProfile: CompetitorProfile = { }, executionLimits: { value: - 'Plan-gated: synchronous API calls time out at 5 minutes on the free plan and 50 minutes on paid plans; async calls default to 90 minutes, while Enterprise policy can be configured up to 7 days; concurrency ranges from 10 to 1,000 executions per billing account depending on plan', + 'Plan-gated: synchronous runs time out at 5 minutes on the free plan and 50 minutes on paid plans; async runs default to 90 minutes, while Enterprise policy can be configured up to 7 days; concurrency ranges from 10 to 1,000 executions per billing account depending on plan', detail: - 'An async API request may set a shorter server-side timeout but cannot exceed its account policy. Concurrency limits are published in the platform cost docs, and Enterprise limits are customizable. Request bodies are separately capped at 10 MB.', + 'A direct async API request can shorten the account policy for that request, but cannot extend it. Concurrency limits are published in the platform cost docs, where the Enterprise limit is 1,000 by default and customizable. A run that exceeds its time limit is terminated and marked failed with a timeout error.', shortValue: '5-50 min sync; async defaults to 90 min, Enterprise up to 7 days', confidence: 'verified', sources: [ { url: 'https://docs.sim.ai/platform/costs#concurrent-executions', label: 'Sim Docs: Concurrent Executions', - asOf: '2026-07-13', + asOf: '2026-08-10', }, { - url: 'https://github.com/simstudioai/sim/blob/main/apps/sim/lib/core/execution-limits/types.ts', - label: 'Sim codebase: per-plan execution timeouts', - asOf: '2026-08-03', + url: 'https://docs.sim.ai/platform/costs#run-time-limits', + label: 'Sim Docs: Run Time Limits', + asOf: '2026-08-10', }, { url: 'https://github.com/simstudioai/sim/blob/main/apps/sim/lib/billing/calculations/usage-reservation.ts', diff --git a/apps/sim/lib/compare/data/types.ts b/apps/sim/lib/compare/data/types.ts index 91dc96c0065..1153af7f227 100644 --- a/apps/sim/lib/compare/data/types.ts +++ b/apps/sim/lib/compare/data/types.ts @@ -101,6 +101,8 @@ export interface ComparisonFacts { integrationCount: Fact triggerTypes: Fact customCodeSteps: Fact + /** Whether a code step's execution environment is user-configurable — declaring third-party packages, OS-level system packages, and preinstalled CLI binaries — versus running only on a fixed image whose dependency set the vendor controls. */ + codeSandboxRuntime: Fact apiPublishing: Fact /** Official client SDKs, plugin/custom-node development kits, and a marketplace for community-built integrations. */ extensibilitySdk: Fact @@ -132,6 +134,8 @@ export interface ComparisonFacts { piiRedaction: Fact /** SAML/OIDC single sign-on with organization auto-provisioning on first login. */ sso: Fact + /** Admin-configurable bounds on how long a signed-in session may live: an absolute lifetime cap from sign-in and/or an inactivity timeout, enforced org-wide. Distinct from SSO itself and from a fixed platform-wide session length the customer cannot change. */ + sessionPolicy: Fact /** Whether integrations/tools/skills come from a vetted first-party catalog authored and reviewed by the vendor, versus an open marketplace where any third party can publish and users install executable code from unvetted authors. */ thirdPartyVetting: Fact } From a3a39f479d653bef4d9aa39acd1f51be6bce3df6 Mon Sep 17 00:00:00 2001 From: Waleed Latif Date: Mon, 10 Aug 2026 18:24:39 -0700 Subject: [PATCH 2/2] fix(comparisons): resolve customCodeSteps contradictions for Retool and Workato Both profiles documented code steps in the new codeSandboxRuntime row while their adjacent customCodeSteps row still read Unknown/unclear, so the rendered table gave contradictory answers for the same capability. Settle both from the vendor docs already cited by the sandbox row. --- .../lib/compare/data/competitors/retool.ts | 21 ++++++++++++++----- .../lib/compare/data/competitors/workato.ts | 18 +++++++++++++--- 2 files changed, 31 insertions(+), 8 deletions(-) diff --git a/apps/sim/lib/compare/data/competitors/retool.ts b/apps/sim/lib/compare/data/competitors/retool.ts index 7018b673566..5f4fb90bfb3 100644 --- a/apps/sim/lib/compare/data/competitors/retool.ts +++ b/apps/sim/lib/compare/data/competitors/retool.ts @@ -644,11 +644,22 @@ export const retoolProfile: CompetitorProfile = { sources: [], }, customCodeSteps: { - value: 'Unknown', - detail: 'Not publicly documented.', - shortValue: 'Not publicly documented', - confidence: 'unknown', - sources: [], + value: + 'Yes: a workflow Code block runs custom Python or JavaScript as a step, with the language chosen per block', + shortValue: 'Code block runs custom Python or JavaScript', + confidence: 'verified', + sources: [ + { + url: 'https://docs.retool.com/workflows/guides/blocks/python', + label: 'Execute Python with the Code block | Retool Docs', + asOf: '2026-08-10', + }, + { + url: 'https://docs.retool.com/workflows/guides/blocks/javascript', + label: 'Execute JavaScript with the Code block | Retool Docs', + asOf: '2026-08-10', + }, + ], }, codeSandboxRuntime: { value: diff --git a/apps/sim/lib/compare/data/competitors/workato.ts b/apps/sim/lib/compare/data/competitors/workato.ts index 2b41a5aae73..78bb10089cd 100644 --- a/apps/sim/lib/compare/data/competitors/workato.ts +++ b/apps/sim/lib/compare/data/competitors/workato.ts @@ -717,10 +717,22 @@ export const workatoProfile: CompetitorProfile = { }, customCodeSteps: { value: - 'Not documented whether recipes support inline custom-code steps (e.g. Ruby/JS snippets). Workato offers a Ruby-based Custom SDK for building custom connectors instead, a related but separate capability', - shortValue: 'Unclear; Ruby SDK exists for custom connectors', - confidence: 'estimated', + 'Yes: recipes run inline custom code through the Python snippets and JavaScript snippets connectors, alongside a separate Ruby-based Custom SDK for authoring custom connectors', + detail: + 'The snippets connectors execute code as a recipe step, on Python 3.9 or later and Node.js 20.11.0 respectively. The Ruby SDK is a distinct capability for building reusable connectors rather than adding a code step to a recipe.', + shortValue: 'Python and JavaScript snippet connectors run inline code', + confidence: 'verified', sources: [ + { + url: 'https://docs.workato.com/connectors/python.html', + label: 'Python snippets by Workato | Workato Docs', + asOf: '2026-08-10', + }, + { + url: 'https://docs.workato.com/connectors/javascript.html', + label: 'JavaScript snippets by Workato | Workato Docs', + asOf: '2026-08-10', + }, { url: 'https://docs.workato.com/developing-connectors.html', label: 'Universal connectors | Workato Docs',