> For the complete documentation index, see llms.txt.
Skip to main content

Check out Port for yourself ➜ 

Claude managed agents

ClaudeAI iconClaudeAI icon
Loading version...

Port's Claude Managed Agents integration surfaces your Anthropic agents, environments, sessions, vaults, and memory stores in your Context Lake. From there, you can trigger agent sessions directly from Port workflows or let platform engineers create new agents through self-service forms.

Core support

For a full end-to-end example that combines both a create-agent and a trigger-agent workflow, see the guide Assign PR reviewers with a Claude managed agent.

Trigger a Claude agent​

Use this workflow to start a new session or continue an existing one, and send a user message to the agent. See the Claude managed agents integration action page for the full workflow JSON and node field reference. For a worked example, see the guide Assign PR reviewers with a Claude managed agent.

GitHub repository resources

When a session includes a github_repository resource and githubAuthorizationToken is configured on the integration, the token is automatically injected so the session can clone and push to the repository. This works without the GitHub MCP server. To also open pull requests, the agent needs a vault with GitHub MCP credentials (see the MCP server setup section on the integration action page).

Create a Claude agent​

Use this workflow to let platform engineers or developers create a new Claude managed agent through a self-service form. See the Claude managed agents integration action page for the full workflow JSON and node field reference. For a worked example, see the guide Assign PR reviewers with a Claude managed agent.

MCP server setup​

Agents can use Port MCP or GitHub MCP during sessions. Both require a Claude credential vault with the appropriate token. For the full credential setup steps, see MCP server setup on the integration action page.

Prerequisites​

Setup​

Choose one of the installation methods below. If you are not sure which option to use, review the installation methods overview.

Configuration​

Port integrations use a YAML mapping block to ingest data from the third-party API into Port.

The mapping uses the JQ JSON processor to transform fields and shape incoming Claude data into Port entities.

Webhook configuration​

On start, when the event listener can process webhooks and a public base URL is set, the integration auto-configures a Claude Platform webhook (creates it if missing, or merges any missing events if one already exists) that points at:

<base_url>/integration/webhook

Live events update agent, environment, session, vault, and memory-store. These resources are also refreshed on resync. Skill entities are updated on resync only.

ResourceLive webhooksResync
agentYesYes
environmentYesYes
sessionYesYes
vaultYesYes
memory-storeYesYes
skillNoYes

The webhook is subscribed to:

  • Session: session.status_run_started, session.status_idled, session.status_rescheduled, session.status_terminated, session.deleted, session.updated
  • Agent: agent.created, agent.updated, agent.archived, agent.deleted
  • Environment: environment.created, environment.updated, environment.archived, environment.deleted
  • Memory store: memory_store.created, memory_store.archived, memory_store.deleted
  • Vault: vault.created, vault.archived, vault.deleted

By installation method​

Hosted by Port

No manual Claude Console setup is required. On start, the integration auto-configures the webhook and stores the signing secret returned on create as a Port organization secret, then sets webhookSigningSecret on the integration spec. verifyWebhookSecrets defaults to true for new installs.

Self-hosted (realtime)

The integration auto-configures the webhook when the event listener processes webhooks and OCEAN__BASE_URL / liveEvents.baseUrl is a publicly reachable URL.

Claude shows the signing secret only once, when the webhook is created. On self-hosted installs that secret is kept in memory for the current process. Webhooks are still handled if the secret is not configured; signature verification is skipped. To enable verification across restarts, rotate the signing secret in Claude Console (Manage > Webhooks), then set the new value as webhookSigningSecret (Helm: integration.config.webhookSigningSecret, or OCEAN__INTEGRATION__CONFIG__WEBHOOK_SIGNING_SECRET).

CI / one-shot (ONCE event listener)

CI installs do not receive live events. The ONCE listener skips webhook registration, so catalog updates happen only when the pipeline runs. You do not need to configure webhookSigningSecret for CI.

Signature verification​

When verifyWebhookSecrets is true (the default) and webhookSigningSecret is configured, the integration validates the Standard Webhooks signature on every request and rejects invalid signatures. If no signing secret is configured, webhooks are still processed and verification is skipped (a warning is logged).

Self-hosted signing secret

Only self-hosted realtime installs need you to persist webhookSigningSecret yourself (usually after rotating it in Claude Console, since Claude shows it only once). Hosted by Port stores it automatically. CI installs do not use live webhooks.

Default mapping configuration​

Default mapping configuration (click to expand)
resources:
- kind: environment
selector:
query: 'true'
port:
entity:
mappings:
identifier: .id
title: .name
blueprint: '"claude_environment"'
properties:
description: .description
scope: .scope
environmentType: .config.type
metadata: .metadata
createdAt: .created_at
updatedAt: .updated_at
archivedAt: .archived_at
- kind: vault
selector:
query: 'true'
port:
entity:
mappings:
identifier: .id
title: .display_name
blueprint: '"claude_vault"'
properties:
metadata: .metadata
createdAt: .created_at
updatedAt: .updated_at
archivedAt: .archived_at
- kind: memory-store
selector:
query: 'true'
port:
entity:
mappings:
identifier: .id
title: .name
blueprint: '"claude_memory_store"'
properties:
description: .description
metadata: .metadata
createdAt: .created_at
updatedAt: .updated_at
archivedAt: .archived_at
- kind: skill
selector:
query: 'true'
port:
entity:
mappings:
identifier: .id
title: '.display_title // .id'
blueprint: '"claude_skill"'
properties:
displayTitle: .display_title
source: .source
latestVersion: .latest_version
createdAt: .created_at
updatedAt: .updated_at
- kind: agent
selector:
query: 'true'
port:
entity:
mappings:
identifier: .id
title: .name
blueprint: '"claude_agent"'
properties:
description: .description
model: .model.id
system: .system
version: .version
metadata: .metadata
mcpServers: '[.mcp_servers[]?.name] // []'
createdAt: .created_at
updatedAt: .updated_at
archivedAt: .archived_at
relations:
skills: '[.skills[]? | select(.type == "custom") | .skill_id]'
delegateAgents: '[.multiagent.agents[]?.id] // []'
- kind: session
selector:
query: 'true'
port:
entity:
mappings:
identifier: .id
title: '.title // .id'
blueprint: '"claude_session"'
properties:
status: .status
inputTokens: .usage.input_tokens
outputTokens: .usage.output_tokens
cacheReadInputTokens: .usage.cache_read_input_tokens
activeSeconds: .stats.active_seconds
durationSeconds: .stats.duration_seconds
agentVersion: .agent.version
githubRepositories: '[.resources[]? | select(.type == "github_repository") | .url]'
metadata: .metadata
createdAt: .created_at
updatedAt: .updated_at
archivedAt: .archived_at
relations:
agent: .agent.id
environment: .environment_id
memoryStores: '[.resources[]? | select(.type == "memory_store") | .memory_store_id]'
vaults: .vault_ids

Mapping & examples per resource​

To view and test the integration mapping against sample API responses, use the jq playground in your connectors page.

Monitoring and sync status​

To learn more about how to monitor and check the sync status of your integration, see the relevant documentation.