Skip to main content
Most failed calls come from a handful of small mistakes in how a tool is called, not from the platform being down. This page lists the ones people hit most, with the exact fix for each. If your AI hits an error, paste the error text and the matching fix below back into the chat.

​
git_read or git_push fails even though I saved my token

This is the single most common stumble. The GitHub fields look for your token in the vault under a recognised name. If you saved it under a different name, the tool cannot find it and the call fails.
The token must be saved under a recognised GitHub name. GITHUB_TOKEN is the canonical one. Saving it as GIT_PAT, MY_TOKEN, or with a typo means git_read, git_push, code_edit, and safe_deploy cannot see it.
Fix. Save (or re-save) your token under the name GITHUB_TOKEN: 
{
  "name": "ub_write",
  "arguments": {
    "secrets_vault": {
      "action": "save",
      "secret_name": "GITHUB_TOKEN",
      "secret_value": "ghp_your_token_here"
    }
  }
}
Then confirm it is there: 
{ "name": "ub_write", "arguments": { "secrets_vault": { "action": "list" } } }
You should see GITHUB_TOKEN in the returned list of names. Retry your git_read or git_push and it will resolve. Workaround if you cannot rename right now. Every GitHub operation can also be done with proxy_http plus the GitHub REST API, passing the token in an Authorization header yourself. It is more verbose but always works: 
{
  "name": "ub_write",
  "arguments": {
    "proxy_http": {
      "method": "GET",
      "url": "https://api.github.com/repos/your-org/your-repo/contents/README.md",
      "headers": {
        "Authorization": "Bearer ghp_your_token_here",
        "Accept": "application/vnd.github+json"
      }
    }
  }
}

​
secrets_vault says my field is missing or the action is invalid

The vault uses specific field names. Two near-misses account for almost every failure here.
The action is save, not set or store. The name field is secret_name, not key or name. The value field is secret_value, not value.
Wrong (these will fail): 
{ "secrets_vault": { "action": "set", "key": "STRIPE_KEY", "value": "sk_live_xxx" } }
Right: 
{
  "name": "ub_write",
  "arguments": {
    "secrets_vault": {
      "action": "save",
      "secret_name": "STRIPE_KEY",
      "secret_value": "sk_live_xxx"
    }
  }
}
Valid actions are save, list, get, and delete. Only save needs secret_value. get and delete need secret_name. list needs neither.

​
My database call fails with an auth or connection error

Database fields auto-inject your credentials, but only when they are saved under the names the injector looks for. Fix. Save your connection details under SUPABASE_URL and SUPABASE_KEY: 
{
  "name": "ub_write",
  "arguments": {
    "secrets_vault": {
      "action": "save",
      "secret_name": "SUPABASE_URL",
      "secret_value": "https://yourproject.supabase.co"
    }
  }
}
Repeat for SUPABASE_KEY. Any PostgreSQL-compatible database works as long as the URL and key are reachable. After saving both, retry db_select, db_query, or db_write.

​
A field says it is required but I thought I sent it

Each tool reads its fields from the arguments object. A field nested one level too deep, or placed on the wrong tool, reads as missing. Common causes:
  • The field is on the wrong tool. code, bash, git_push, and db_write belong to ub_write. db_select, git_read, and file_read belong to ub_read. web_search and invoke_llm belong to ub_ai.
  • The field is a string when it should be an object, or vice versa. For example db_select takes an object, while db_query takes a plain SQL string.
Check the Tools reference for the exact shape of the field you are sending.

​
My code ran but timed out

Each code and bash call has a 60 second runtime cap. Fix. For long work, split it across calls using a shared session_id so state stays warm between calls, or use parallel_blocks to run independent pieces at the same time: 
{
  "name": "ub_write",
  "arguments": {
    "parallel_blocks": [
      { "code": "# fetch source A" },
      { "code": "# fetch source B" },
      { "code": "# fetch source C" }
    ]
  }
}
Three blocks that each take a few seconds finish in the time of the slowest one, not the sum.

​
proxy_http refuses my URL

proxy_http blocks internal network addresses, loopback, link-local ranges, and cloud metadata endpoints by design, to prevent server side request forgery. Only public http and https URLs are accepted. Fix. Point the call at a public endpoint. If you are trying to reach something on a private network, that is intentionally not reachable from the sandbox.

​
A large response came back cut off

Response bodies above a fixed size are truncated and flagged in the response. Database reads report returned, total, and truncated so you always know when there is more. Fix. Narrow the request. Add a limit and specific select columns to db_select, or filter the rows down. For large files, read in ranges rather than all at once.

​
Still stuck

If an error does not match anything here, paste the full error text into your chat and ask your AI to read it against the Tools reference. If you believe it is a platform issue, contact hello@universalbench.dev.