Credentials and integrations
Fixes for credentials, GitHub, and other connected services. Marshal injects a credential at request time. The agent never sees the secret.
Space cannot start: credential unavailable
You see: This space cannot start: credential "<name>" is not available to you.
See Spaces. In short, ask the owner to share the credential again, bind one you own, or ask an admin to move it to the team or the organization.
Saving a credential needs a JSON object
You see: the value must be a JSON object with the fields ...
Cause: The package method expects a value with named fields, and your value was a plain string. The message lists the field names. For example, the Claude Code api-key method needs the field apiKey, and the token method needs the field token.
Fix: In the web app, use the credential type that matches the package and method, such as claude-code.token or claude-code.api-key. Fill each field in the form. If you create the credential some other way, send a JSON object, for example {"token":"..."}.
Saving a credential fails on format
You see: <field> does not match the format this connection expects
Cause: The package declares a format for the field, and your value does not match it. The message shows the pattern and an example. For example, a Claude API key must start with sk-ant-api, sk-ant-svc, or sk-ant-usr. Marshal does not repeat your value in the message.
Fix: Copy the value again from the service. Check for extra spaces or a cut-off paste. Make sure you chose the right method. A Claude setup token starts with sk-ant-oat and belongs to the token method, not api-key.
A credential value is too short
You see: <field> must be at least N characters
Cause: The value is shorter than the package allows.
Fix: Paste the full value.
A connection needs to be reconnected
You see: This connection needs to be reconnected before an agent can use it.
Cause: The sign-in for that service ended or was refused. The Connections page shows a reconnect badge. Spaces that use the connection cannot use it until you reconnect.
Fix: Open the Connections page and press reconnect on the card marked Needs reconnect. If the toast Couldn't connect <name> appears after the service redirects back, try again. If it repeats, an admin opens Settings > OAuth apps and checks the package’s connect mode, and the own app’s inputs when your org uses its own app.
Sign-in fails with “Mismatching redirect URI”
You see: The service’s page says Mismatching redirect URI, redirect_uri_mismatch or that the redirect address is not allowed, instead of the consent screen.
Cause: The service sends people back only to addresses its app allows, and the address Marshal sends is not on that list yet.
Fix: An admin opens Settings > OAuth apps, selects Configure on the package’s row and selects Copy next to the Redirect URI. Paste it into the allowed redirect URLs of the app at the service. Each connect mode has its own address, so copy it again after you change the mode. Then select Test connection to confirm.
Sign-in fails because the cell cannot reach the service
You see: Connecting with DCR from this cell fails with a message that a host is not in the package's egress hosts, or that the cell refused the request because the address is not public. The mode shows as disabled with the same reason.
Cause: For DCR from this cell, your cell talks to the service directly. It reads the service’s metadata, registers a client and exchanges tokens. Each of those hosts must be one the package may reach, and each must resolve to a public address on port 443.
Fix: An admin checks that the service’s metadata, registration and token hosts are all in the package’s egress hosts, and that they resolve to public addresses. The message names the host that is missing. If the service sits on a private network, pick Own app instead.
A connect is refused because the chosen mode cannot connect
You see: the connect mode <mode> chosen for this integration cannot connect: <reason>
Cause: An admin pinned a connect mode for this package, and that mode cannot connect right now. The reason says why. For example, the Auth Broker was turned off, the service does not offer registration, or the org’s own app is disabled or was deleted. Marshal runs only the mode that was chosen, so the path stays predictable.
Fix: An admin opens Settings > OAuth apps and finds the package’s row, which shows the warning. Either fix what the reason names, for example enable the own app and select Test connection, or pick another mode. Automatic chooses a working path for you.
GitHub: git push is refused
You see: git push fails with Resource not accessible by integration
Cause: The Marshal GitHub App installation needs read and write on Contents to push. To let the agent open pull requests, it also needs read and write on Pull requests and Issues. When the App’s permissions change, a GitHub organization owner accepts the new set. The installation uses the accepted set.
Fix: A GitHub organization owner opens the organization settings on GitHub, then GitHub Apps, then the Marshal app, and accepts the permission update. Try again in a new space. If you use a personal access token instead, check that its scopes allow pushing to the repository.
GitHub: push rejected for workflow file changes
You see: A push that changes a file under .github/workflows/ is rejected with refusing to allow a GitHub App to create or update workflow. Other pushes work.
Cause: Changing workflow files needs the Workflows permission on the Marshal GitHub App.
Fix: A GitHub organization owner grants the Workflows permission to the app and accepts the update. Grant it only if your agents need to edit workflow files.
GitHub: no consent screen on sign-in
You see: Sign in with GitHub does not show GitHub’s screen to authorize the Marshal app.
Cause: The Marshal GitHub App is not installed on your GitHub organization yet. The App must be installed before anyone can authorize.
Fix: A GitHub organization owner installs the App on the organization and picks the repositories. Then each person signs in again.
Git refuses a command that sets config
You see: refusing to run git: its own arguments set "<key>", a git configuration key the tool proxy must control itself
Cause: Git runs through a Marshal proxy, next to your credentials. Some git settings name a program for git to run, such as core.hooksPath, core.sshCommand, core.fsmonitor, the gpg.* programs, and credential.*.helper. The proxy sets these itself, so that no command can run its own program beside your credentials. A command that sets one of them with -c is refused, and the message names the key.
Fix: Remove that -c setting from the command and run it again. The proxy supplies a safe value.
A tool call was refused: credential path
You see: tool call refused: argument 2 points at material the session keeps private (credentials, protected-path). The message can also name the working directory or an environment variable you set.
Cause: Tools that need a credential run in a protected part of the space, next to the credential files. Marshal gives each tool what it needs to sign in, so no command has to name those files. A call that names the credential directory, the session manifest, another process’s /proc entry, a directory that contains them (such as / or /run), a link that leads to one of them, or an environment variable that points at one is refused before the tool starts. A command that lists the whole filesystem root through one of these tools is refused for the same reason. Each refusal is recorded in the space’s audit trail with the tool and the reason, never the argument.
Fix: Remove the path from the command and run it again. The tool signs in on its own. If you need a secret value in your own script, store it as a secret in the manifest and read it from the environment variable it is bound to.
A tool prints a marker where a token should be
You see: [redacted-by-marshal] in the output of a tool such as gh auth token, kubectl config view --raw or an error message that echoes a config file.
Cause: Marshal replaces every credential value it holds in the output of a tool before you see it, including common encodings of the value (base64, URL-encoded, JSON-escaped). A command that prints a token to hand to another program receives the marker instead.
Fix: Let the tool sign in itself. For a program that needs a token, bind a secret to it in the manifest so the program receives a placeholder that Marshal swaps for the real value on the way out.
Variables that make a program load code you chose, such as LD_PRELOAD, PYTHONPATH, BASH_ENV, NODE_OPTIONS and the GIT_TRACE family, are not passed from your shell to tools that run beside the credentials. The tool runs as usual without them. PAGER and EDITOR are set to plain values (cat, false) for these tools, so a command never waits on an editor or a pager nobody can see.
Credentials stay protected in layers: the agent’s own shell never has the credential directory, tool calls that name it are refused, and output is cleaned. These layers work together with the network controls and the audit trail. They are one part of how Marshal keeps secrets away from agents, not a replacement for limiting which tools and networks a manifest allows.
Atlassian: consent screen or redirect fails
Cause: Atlassian lets an admin choose which domains may start a sign-in to its hosted MCP server. Your Atlassian organization has not allowed the address that Marshal redirects back to.
Fix: An Atlassian admin opens Admin, Rovo, Rovo MCP server, Domains and adds the domain that Marshal signs in from. The redirect address has the form <sign-in address>/oauth/callback/atlassian-mcp. Your Marshal admin can tell you the sign-in address. Or skip OAuth: use the mcp-token method with your email and an Atlassian API token.
AWS: Needs sign in
You see: A connection made with Sign in with AWS SSO shows Needs sign in. A space that needs it is refused with Sign in to AWS, or an aws command in a running space says the connection needs sign in.
Cause: The AWS sign-in session ended. Your AWS admin sets how long it lasts, from 15 minutes to 90 days. An admin can also end it, remove your role, or disable your user. A connection also stops after 90 days at the latest.
Fix: Open Connections and choose Reconnect on the connection, or use the Reconnect button on the message. Approve the code on the AWS page. Spaces that already use the connection work again on their next aws command, with no restart. If you do not own the connection, ask the owner or a team lead to reconnect it.