API failing

[north rivet]

I'm trying to ask openclaw through discord to use an API, but it's not working. It's running on an M4 mac mini. Here's what openclaw is telling me:

It seems like you are asking for a full technical diagnostic review of why the API calls are failing, given the context of the last few attempts.

1. What's Happening:
   Every time we try to execute a command that interacts with the external api.congress.gov—whether through web_fetch, exec calling curl, or web_search simulating the call—it fails because the execution environment lacks the necessary credentials or library support to make the call successfully.

2. Why It's Failing (The Three Potential Blockers):

• Blocker A: Authentication (Most Likely): The API requires a key. While I can store it, the exec tool needs to be able to use it via an environment variable (export) and the script needs to successfully handle the API's specific authentication header format. The multiple failures suggest the shell context is discarding the variable before the final python3 command runs correctly.
• Blocker B: Dependency Management: The zsh: command not found: pip error confirmed that the environment running python3 is not set up to manage external Python libraries like requests.
• Blocker C: Security/Rate Limits: The 403 Forbidden errors from web_fetch are a security measure by Congress.gov itself, which blocks automated scraping of its structured pages.

[crystal estuary]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[strange inlet]

First thing: what does openclaw --version show?

The diagnosis OpenClaw gave you is probably overcomplicating it. Congress.gov’s API does require an API key, and api.data.gov supports passing it as an X-Api-Key header. web_fetch is mostly for fetching/extracting readable web pages, not a great fit for authenticated API calls with custom headers. Use exec + curl or a tiny stdlib Python script instead.

Quick local sanity check on the Mac mini, without pasting your key into Discord:

export CONGRESS_API_KEY='your-key-here'
curl -sS -D /tmp/congress.headers \
  -H "X-Api-Key: $CONGRESS_API_KEY" \
  "https://api.congress.gov/v3/bill?format=json&limit=1" | head

grep -i '^http/\|^x-ratelimit' /tmp/congress.headers

If that works in Terminal but fails when asking through Discord, then the problem is likely OpenClaw’s exec environment/policy, not Congress.gov. Put the key somewhere the gateway process can see it, for example ~/.openclaw/.env:

[strange inlet]

CONGRESS_API_KEY=your-key-here

Then restart the gateway and ask the agent to use exec with curl -H "X-Api-Key: $CONGRESS_API_KEY" ..., not web_fetch, and not requests/pip. pip is a distraction here; curl or Python stdlib is enough.

Useful docs:
https://docs.openclaw.ai/help/faq
https://docs.openclaw.ai/tools/exec
https://docs.openclaw.ai/help/environment

Also: don’t paste the API key or full keyed URL into the thread. If this turns out to be an OpenClaw bug, the next useful artifacts are openclaw status --all and the relevant redacted log lines.

[north rivet]

It should be the most recent version of openclaw - I just installed it yesterday. how do i put the key somewhere the gateway process can see it? Or check if it's already there?

[strange inlet]

Still run openclaw --version when you can — “installed yesterday” is useful, but the exact version saves a lot of guesswork.

For the key: the easiest place is ~/.openclaw/.env. OpenClaw loads that for the gateway, and it does not override already-set environment variables.

Check whether it’s already configured without printing the secret:

if grep -q '^CONGRESS_API_KEY=' ~/.openclaw/.env 2>/dev/null; then
  echo 'CONGRESS_API_KEY is present in ~/.openclaw/.env'
else
  echo 'CONGRESS_API_KEY is not in ~/.openclaw/.env'
fi

Add it safely without showing the key in your shell history:

[strange inlet]

mkdir -p ~/.openclaw
printf 'Paste Congress.gov API key: '
IFS= read -rs CONGRESS_API_KEY
echo
printf '
CONGRESS_API_KEY=%s
' "$CONGRESS_API_KEY" >> ~/.openclaw/.env
unset CONGRESS_API_KEY
openclaw gateway restart

Then test whether a fresh shell can load it and call the API:

set -a

[strange inlet]

. ~/.openclaw/.env
set +a
curl -sS -D /tmp/congress.headers \
  -H "X-Api-Key: $CONGRESS_API_KEY" \
  'https://api.congress.gov/v3/bill?format=json&limit=1' | head

grep -i '^http/\|^x-ratelimit' /tmp/congress.headers

After restart, ask OpenClaw through Discord to use exec with curl and the env var, not web_fetch. Something like: “Use exec to run curl against the Congress.gov API using $CONGRESS_API_KEY from the environment. Do not print the key.”

Docs for the env loading behavior: https://docs.openclaw.ai/help/environment

[north rivet]

OpenClaw 2026.5.19 (a185ca2)

[strange inlet]

That version is recent enough for the ~/.openclaw/.env path I mentioned.

After adding CONGRESS_API_KEY=... there and restarting with:

openclaw gateway restart

the key should be available to gateway/exec runs. To verify without exposing it, ask OpenClaw in Discord to run:

if [ -n "$CONGRESS_API_KEY" ]; then echo 'CONGRESS_API_KEY is visible'; else echo 'CONGRESS_API_KEY is missing'; fi

If it says missing after restart, the next thing to check is whether the gateway is running under a different home/state dir:

[strange inlet]

openclaw status --all
openclaw gateway status

Those should show the config/state paths. Don’t paste the whole output if it includes anything sensitive, but the paths and redacted env/config bits are useful.

[north rivet]

sorry im new to all this...do i put the above commands into discord, or into the mac mini terminal?

[strange inlet]

No worries — put the setup commands in the Mac mini Terminal, not Discord.

Use Terminal for these parts:

mkdir -p ~/.openclaw
printf 'Paste Congress.gov API key: '
IFS= read -rs CONGRESS_API_KEY
echo
printf '
CONGRESS_API_KEY=%s
' "$CONGRESS_API_KEY" >> ~/.openclaw/.env
unset CONGRESS_API_KEY
openclaw gateway restart

Then in Discord, ask OpenClaw something like:

[strange inlet]

Use exec to check whether CONGRESS_API_KEY is visible. Do not print the key.

If that works, then ask it to call the Congress.gov API using exec + curl. The key itself should only go into Terminal, never into Discord.

[north rivet]

i'm not at my terminal right now, but i used the 'use exec to check' command in discord and here's what it says:

"Exec approval is required, but no interactive approval client is currently available.

Approve it from the Web UI or terminal UI, or enable a native chat approval client such as Discord. If those accounts already know your owner ID via allowFrom or owner config, OpenClaw can often infer approvers automatically. Then retry the command. You can usually leave execApprovals.approvers unset when owner config already identifies the approvers."

[strange inlet]

That means the API/key check did not actually run yet. OpenClaw is stopping before exec because your Mac requires approval for shell commands, and Discord is not currently set up as an approval client.

If you’re not at the Mac mini, you have two options:

1. If you can reach the OpenClaw Dashboard/Web UI remotely, approve the pending exec request there.
2. If you can’t reach the Web UI, wait until you’re at the Mac mini. Nothing is broken yet — it’s just the safety gate doing its job.

When you’re back at the Mac mini, you can enable Discord approval buttons so future exec requests can be approved from Discord. In Terminal, add your Discord user ID as an exec approver. If you already know the numeric Discord user ID you used for setup/allowlist, use that here:

openclaw config set commands.ownerAllowFrom '["discord:YOUR_DISCORD_USER_ID"]'
openclaw config set channels.discord.execApprovals.enabled auto
openclaw config set channels.discord.execApprovals.target dm
openclaw gateway restart

Small correction to the message OpenClaw gave you: current docs call the owner key commands.ownerAllowFrom. Discord exec approvals do not infer approvers from normal channel allowFrom; they need channels.discord.execApprovals.approvers or commands.ownerAllowFrom.

[strange inlet]

Docs: https://docs.openclaw.ai/channels/discord and https://docs.openclaw.ai/tools/exec-approvals

[north rivet]

ok i'm back at my terminal and about to enter the API command...for the line printf do innclude my API key inside of the ' marks or do leave them out?

[strange inlet]

Leave the printf line exactly as written — do not put your API key inside those quotes.

This line just prints a prompt:

printf 'Paste Congress.gov API key: '

After you press Enter on the next line:

IFS= read -rs CONGRESS_API_KEY

paste/type the API key there. It will look like nothing is happening because -s hides what you type. Press Enter after pasting.

So the flow is:

[strange inlet]

printf 'Paste Congress.gov API key: '
IFS= read -rs CONGRESS_API_KEY
echo
printf '
CONGRESS_API_KEY=%s
' "$CONGRESS_API_KEY" >> ~/.openclaw/.env
unset CONGRESS_API_KEY
openclaw gateway restart

Only paste the actual key when Terminal is waiting after IFS= read -rs CONGRESS_API_KEY.

[north rivet]

got it! How cani telll now it worked?

[strange inlet]

Run these in the Mac mini Terminal. They check presence and make one tiny API call without printing the key.

if grep -q '^CONGRESS_API_KEY=' ~/.openclaw/.env 2>/dev/null; then
  echo 'Key is saved in ~/.openclaw/.env'
else
  echo 'Key is NOT saved in ~/.openclaw/.env'
fi

Then test the API:

set -a
. ~/.openclaw/.env
set +a

[strange inlet]

curl -sS -D /tmp/congress.headers \
  -H "X-Api-Key: $CONGRESS_API_KEY" \
  'https://api.congress.gov/v3/bill?format=json&limit=1' | head

grep -i '^http/\|^x-ratelimit' /tmp/congress.headers

What you want to see:

HTTP/... 200
x-ratelimit-limit: ...
x-ratelimit-remaining: ...

If you see 403, the key is missing/invalid/not verified, or the header didn’t get sent. If Terminal works but Discord/OpenClaw still fails, then the next issue is exec approvals or gateway env loading, not the Congress API key itself.

[north rivet]

here's what it gave me:

{
"error": {
"code": "API_KEY_MISSING",
"message": "No api_key was supplied. Get one at https://api.congress.gov:443"
}
}HTTP/2 403

[strange inlet]

That means the request reached Congress.gov, but the key did not get sent. Most likely CONGRESS_API_KEY is empty in that Terminal session, or it didn’t get saved into ~/.openclaw/.env correctly.

Run this in Terminal. It will not print the key, only the length:

set -a
. ~/.openclaw/.env
set +a
printf 'CONGRESS_API_KEY length: %s
' "${#CONGRESS_API_KEY}"

If it prints 0, the key is not loaded. Check whether the line exists without revealing it:

grep -n '^CONGRESS_API_KEY=' ~/.openclaw/.env | sed 's/=.*/=<hidden>/'

[strange inlet]

If that prints nothing, add it again and make sure you paste the key after the hidden read line:

printf 'Paste Congress.gov API key: '
IFS= read -rs CONGRESS_API_KEY
echo
printf '
CONGRESS_API_KEY=%s
' "$CONGRESS_API_KEY" >> ~/.openclaw/.env
unset CONGRESS_API_KEY

Then retry the length check. Once length is nonzero, test with the query-param form, which is easiest to debug:

set -a

[strange inlet]

. ~/.openclaw/.env
set +a
curl -sS -D /tmp/congress.headers \
  "https://api.congress.gov/v3/bill?format=json&limit=1&api_key=$CONGRESS_API_KEY" | head

grep -i '^http/\|^x-ratelimit' /tmp/congress.headers

You want HTTP/2 200. If the length is nonzero but you still get API_KEY_MISSING, paste the exact command you ran, but not the key.

[north rivet]

it says the length is 40...hoow can i test it again?

[strange inlet]

Good, length 40 is the expected shape for an api.data.gov key.

Run this exact test in Terminal. It uses the query parameter form so there’s less shell/header weirdness:

set -a
. ~/.openclaw/.env
set +a
curl -sS -D /tmp/congress.headers \
  "https://api.congress.gov/v3/bill?format=json&limit=1&api_key=$CONGRESS_API_KEY" | head

grep -i '^http/\|^x-ratelimit' /tmp/congress.headers

If it works, you should see HTTP/2 200 and some JSON with bills.

If it still says API_KEY_MISSING, run this next — it shows whether the URL contains an api_key parameter without showing the key:

[strange inlet]

url="https://api.congress.gov/v3/bill?format=json&limit=1&api_key=$CONGRESS_API_KEY"
case "$url" in
  *api_key=) echo 'api_key parameter is empty' ;;
  *api_key=*) echo 'api_key parameter is present' ;;
esac

If it says present but Congress still says missing, try the header form again:

curl -sS -D /tmp/congress.headers \
  -H "X-Api-Key: $CONGRESS_API_KEY" \
  'https://api.congress.gov/v3/bill?format=json&limit=1' | head

grep -i '^http/\|^x-ratelimit' /tmp/congress.headers

[north rivet]

it looks like that worked! Now how can i make sure it's working through my discord chat with openclaw

[strange inlet]

Nice, that means the key itself is good.

Now make sure the Gateway has reloaded it:

openclaw gateway restart

Then in your Discord chat with OpenClaw, ask this first:

Use exec to run: if [ -n "$CONGRESS_API_KEY" ]; then echo "CONGRESS_API_KEY is visible"; else echo "CONGRESS_API_KEY is missing"; fi
Do not print the key.

If exec approval pops up, approve it from the Web UI/Terminal UI. If it says the key is visible, test the actual API from Discord with:

[strange inlet]

Use exec and curl to call https://api.congress.gov/v3/bill?format=json&limit=1 using the CONGRESS_API_KEY environment variable as the api_key query parameter. Do not print the key. Tell me only whether the HTTP status is 200 and summarize the first bill returned.

If Terminal worked but Discord says CONGRESS_API_KEY is missing, the gateway is probably reading a different env/state path or didn’t restart cleanly. Then run this in Terminal and share only the non-secret path/status parts:

openclaw gateway status
openclaw status --all

[north rivet]

i got the response 'LLM request timed out' for the first command: Use exec to run: if [ -n "$CONGRESS_API_KEY" ]; then echo "CONGRESS_API_KEY is visible"; else echo "CONGRESS_API_KEY is missing"; fi
Do not print the key.

[strange inlet]

That timeout happened before we got a useful exec result, so it doesn’t tell us whether the API key is visible yet. It’s an OpenClaw/model request timeout, not a Congress.gov API response.

Try a shorter Discord prompt first:

Use exec to check whether CONGRESS_API_KEY exists. Do not print its value.

If that also times out, check the Gateway/model side from the Mac mini Terminal:

openclaw status
openclaw models status
openclaw logs --follow

Then send another short message to OpenClaw like:

[strange inlet]

Say only: ready

If even that times out, the issue is not the API key anymore — it’s the active model/provider or gateway session getting stuck. In that case, openclaw status --all is the most useful next output, with secrets redacted.

[north rivet]

here's the result (I did not get an approval pormpt in the terminal).Exec approval is required, but no interactive approval client is currently available.

Approve it from the Web UI or terminal UI, or enable a native chat approval client such as Discord. If those accounts already know your owner ID via allowFrom or owner config, OpenClaw can often infer approvers automatically. Then retry the command. You can usually leave execApprovals.approvers unset when owner config already identifies the approvers.

[strange inlet]

That confirms the blocker: exec is still approval-gated, and there’s no approval UI connected. The API key test never ran.

Since you’re at the Mac now, easiest path is to enable Discord approval buttons for yourself, then retry. In Terminal, run these. Use your Discord numeric user ID; from this thread it looks like it may be 1498296894449913856:

openclaw config set commands.ownerAllowFrom '["discord:1498296894449913856"]'
openclaw config set channels.discord.execApprovals.enabled auto
openclaw config set channels.discord.execApprovals.approvers '["1498296894449913856"]'
openclaw config set channels.discord.execApprovals.target dm
openclaw gateway restart

Then go back to Discord and retry:

Use exec to check whether CONGRESS_API_KEY exists. Do not print its value.

[strange inlet]

You should get a Discord DM or approval button/card. Approve it, and then the command should actually run.

Alternative: open the Dashboard/Web UI and go to the exec approvals area, but the Discord approval-button setup is nicer once it’s working.

Docs: https://docs.openclaw.ai/channels/discord and https://docs.openclaw.ai/tools/exec-approvals

[north rivet]

timed out again. how do i try the dashboard/web ui option?

[strange inlet]

Use the Mac mini Terminal for the dashboard launch:

openclaw dashboard

That should open the browser automatically. If it only prints a URL, copy that URL into a browser on the Mac mini.

Once it opens:

1. If it asks to connect/authenticate, use the token/password shown or configured by OpenClaw. openclaw dashboard usually gives you the right link for that.
2. Go to Nodes → Exec approvals.
3. Make sure the target is Gateway.
4. For a temporary test, set the policy to allow the command or reduce prompting enough that exec can run. If there’s a pending approval request visible, approve it there.
5. Retry the Discord prompt: Use exec to check whether CONGRESS_API_KEY exists. Do not print its value.

If the dashboard says unauthorized or won’t connect, run:

[strange inlet]

openclaw dashboard --no-open
openclaw gateway status

and share the non-secret parts. Docs: https://docs.openclaw.ai/web/dashboard and https://docs.openclaw.ai/tools/exec-approvals

[north rivet]

i used the dashboard commannd and it opened a browser with a red message "device pairing required"

[strange inlet]

That’s the Dashboard’s device pairing gate. Approve the browser as a trusted Control UI device from the Mac mini Terminal.

Run:

openclaw devices list

Look for a pending request from the browser you just opened. Then approve that exact request ID:

openclaw devices approve <requestId>

After that, refresh the browser tab. If there’s only one pending request and the CLI offers --latest, you can use:

[strange inlet]

openclaw devices approve --latest

but the safer path is devices list first, then approve the specific ID.

Once the dashboard loads, go to Nodes → Exec approvals, target Gateway, and approve the pending exec request or loosen the policy for your test. Docs: https://docs.openclaw.ai/web/control-ui and https://docs.openclaw.ai/cli/devices

[north rivet]

i was able to open the dashboard. now what

[strange inlet]

Great. Now use the dashboard to clear the exec approval blocker.

In the Dashboard:

1. Open Nodes.
2. Find Exec approvals.
3. Set target to Gateway.
4. If there is a pending approval for the command, approve it.
5. If there is no pending request, set Gateway exec policy temporarily to allow/ask in a way you can approve from the UI, then save.

Then go back to Discord and retry:

Use exec to check whether CONGRESS_API_KEY exists. Do not print its value.

If it says the key is visible, run the real test:

[strange inlet]

Use exec and curl to call the Congress.gov bill endpoint with CONGRESS_API_KEY as the api_key query parameter. Do not print the key. Tell me only the HTTP status and summarize the first bill returned.

If you don’t see Nodes → Exec approvals, tell me what tabs/sections you do see in the dashboard.

[north rivet]

i dont understand how to do your step 5: If there is no pending request, set Gateway exec policy temporarily to allow/ask in a way you can approve from the UI, then save.

[strange inlet]

Yep, that was too vague. Ignore step 5 for now.

Do this simpler flow:

1. Keep the Dashboard open.
2. Go back to Discord.
3. Send OpenClaw this exact message:

Use exec to check whether CONGRESS_API_KEY exists. Do not print its value.

4. After you send that, immediately look back at the Dashboard. A pending exec approval should appear under Nodes → Exec approvals with buttons/actions to approve or deny it.
5. Click Approve once / Allow once for that pending command.

If no approval appears in the Dashboard after retrying from Discord, then use Terminal to inspect the policy:

[strange inlet]

openclaw approvals get --gateway
openclaw exec-policy show

You can paste the output here, but make sure it does not include secrets. Those commands should only show policy/config, not your Congress API key.

[strange inlet]

This output is good news: your Gateway exec policy is already security=full and ask=off, so it should not be waiting for an approval prompt now.

Do this next:

1. Restart once so the running gateway definitely has the current policy/env:

openclaw gateway restart

2. In Discord, retry the shortest possible check:

Use exec to run: echo ok

If that returns ok, then test the key:

[strange inlet]

Use exec to check whether CONGRESS_API_KEY exists. Do not print its value.

If echo ok still says approval required, the Discord session may be stale or routed somewhere other than the gateway. Start a fresh Discord thread/DM/session with OpenClaw and try Use exec to run: echo ok there.

If echo ok works but the key is missing, rerun openclaw gateway restart after confirming the key is in ~/.openclaw/.env.

[north rivet]

hmmm...it still hasn't responded but it's think...the dashboard shows this under nodes devices:GatewayRequestError: JsonFileReadError: Failed to read JSON file: /Users/oc-bbbb1/.openclaw/devices/paired.json <- Error: File changed during read: /Users/oc-bbbb1/.openclaw/devices/paired.json

[strange inlet]

That paired.json message usually means the Dashboard tried to read the device-pairing file while OpenClaw was updating it. It can be transient.

Try this in order:

openclaw gateway restart

Then refresh the Dashboard tab and retry the simple Discord test:

Use exec to run: echo ok

If the Dashboard still shows the same paired.json error after restart, run these in Terminal and share the output:

[strange inlet]

openclaw status
openclaw devices list
openclaw logs --follow

Let logs --follow run while you retry the Discord echo ok test, then copy the relevant error lines. Don’t include tokens or API keys.

At this point we’ve learned: the Congress API key works in Terminal, and your exec policy output says approval should be off. So the remaining issue is likely gateway/session/device state, not Congress.gov.

[strange inlet]

The important line is this one:

stalled session ... activeWorkKind=model_call ... lastProgress=model_call:started

So OpenClaw is stuck waiting on the model/provider before it ever gets to exec. The paired.json read error looks like a dashboard/device-list race; annoying, but not the main blocker.

Do this in the Discord chat where you’re talking to your OpenClaw bot, as a standalone message:

/reset

Then try the smallest possible message:

[strange inlet]

Say only: ready

If that works, then try:

Use exec to run: echo ok

If /reset doesn’t clear it, restart from Terminal:

openclaw gateway restart
openclaw models status

[strange inlet]

Then retry Say only: ready in Discord. If even that stalls, the remaining problem is model/provider config or provider timeout, not exec or the Congress API key. In that case, paste the redacted openclaw models status output.

[north rivet]

i got a pop up window in the dashboard and i sellected approve once

[strange inlet]

Good, that means the Dashboard approval path is working now.

Wait a few seconds and see whether the Discord bot returns the result of that approved command. If it was the echo ok test, you want to see ok.

Then run the next test in Discord:

Use exec to check whether CONGRESS_API_KEY exists. Do not print its value.

If another dashboard approval appears, approve once again. If it says the key is visible, then run:

Use exec and curl to call the Congress.gov bill endpoint with CONGRESS_API_KEY as the api_key query parameter. Do not print the key. Tell me only the HTTP status and summarize the first bill returned.

If it hangs after approval, send /reset in the Discord bot chat and retry the key-visible check.

[north rivet]

after seeing 'ok' i ran the first text and it simply gave an eye emoji but no response, and nothing showed up in the dashboard

[strange inlet]

The eye reaction usually means it saw the message, but it may not have actually run a tool. Since echo ok worked, use a very explicit exec command next.

In Discord, send this exact prompt:

Use exec to run this exact shell command and reply with the output: test -n "$CONGRESS_API_KEY" && echo visible || echo missing
Do not print the key.

If it returns missing, restart the gateway from Terminal so it reloads ~/.openclaw/.env:

openclaw gateway restart

Then retry the same Discord prompt. If it gives only an emoji again, send /reset as a standalone Discord message and retry the exact prompt above.

[north rivet]

even wtih the /reset command it is just giving the eyes emoji

[strange inlet]

If /reset only gets the 👀 reaction, OpenClaw is acknowledging the Discord message but the handler/run is not completing. At this point I’d stop testing the Congress API and check the gateway/model path.

From the machine running OpenClaw, run:

openclaw --version
openclaw status --all
openclaw logs --follow

Then send one fresh Discord message:

Say only: ready

If that still only gets 👀, restart the gateway once:

[strange inlet]

openclaw gateway restart

and retry Say only: ready.

Please paste the openclaw --version and the non-secret/redacted parts of openclaw status --all plus the log lines around the 👀 message. The key thing I’m looking for is whether it says the session is stalled in model_call, waiting on an exec approval, or failing Discord delivery.

Docs for the exact diagnostics path: https://docs.openclaw.ai/help/faq and https://docs.openclaw.ai/gateway/troubleshooting

[north rivet]

after I entered the first three commands it didn't open the normal long; instread it went back to a normal prompt after showing this:

[strange inlet]

That output is useful. Two things:

1. The ^[[200~ / ^[[201~ text is just a terminal paste artifact, so ignore the first zsh: bad pattern error. Type commands one at a time manually if paste keeps doing that.

2. The real clue is here:

Agents │ 1 total · 1 bootstrapping
main   │ Bootstrap file PRESENT

That means the main agent still thinks it is in first-run bootstrap mode. That can make normal Discord messages only get the 👀 ack and never produce a useful reply.

Run this on the Mac mini:

[strange inlet]

mv ~/.openclaw/workspace/BOOTSTRAP.md ~/.openclaw/workspace/BOOTSTRAP.md.bak
openclaw gateway restart

Then retry in Discord:

Say only: ready

If it still only gives 👀, run this as a separate command, not pasted onto the previous one:

openclaw logs --follow

[strange inlet]

Then send one Discord test message and paste the new log lines that appear.

Docs: https://docs.openclaw.ai/start/bootstrapping and https://docs.openclaw.ai/help/faq

[north rivet]

do i enter back and the mv ~ commands in the same prompt, or two separate prompts

[strange inlet]

Two separate Terminal commands, one after the other. Press Enter after each line:

mv ~/.openclaw/workspace/BOOTSTRAP.md ~/.openclaw/workspace/BOOTSTRAP.md.bak

Then:

openclaw gateway restart

After the restart finishes, come back to Discord and send:

Say only: ready

[north rivet]

got eyes only again

[strange inlet]

Got it. The BOOTSTRAP fix probably worked, but these logs still don’t show the actual Discord test message being processed. The important next clue is whether the agent is still bootstrapping or now stuck on the model.

Run this now:

openclaw status --all

Check the Agents row. If it still says:

1 bootstrapping
Bootstrap file PRESENT

then the mv did not actually move the file.

[strange inlet]

If bootstrapping is gone, the next suspect is the model path. Your log shows OpenClaw is using an Ollama/local model. If Say only: ready only gets 👀, that usually means Discord is receiving the message but the agent run is stalling before it can answer. Please run:

openclaw logs --follow

leave that running, send Say only: ready in Discord, then paste only the new lines that appear after that message.

Also run:

openclaw models status

and paste the non-secret output. For model setup context: https://docs.openclaw.ai/concepts/models

[north rivet]

so quick question before I run those -- the prompt in my termnial looks different. it shows ^Cbash-3.2$ instead of oc-bbbb1@Mac-mini ~ %

[strange inlet]

That’s okay. ^C means you pressed Ctrl-C, which stopped whatever command was running. bash-3.2$ just means you’re now in a bash shell instead of zsh. You can still run the same commands there.

Run them one line at a time from that bash-3.2$ prompt:

openclaw status --all

Then, if needed:

openclaw models status

If Terminal ever gets “stuck” following logs, Ctrl-C brings you back to a prompt. That part is normal.

[north rivet]

Agents
┌────────────┬────────────────┬──────────┬──────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Agent │ Bootstrap file │ Sessions │ Active │ Store │
├────────────┼────────────────┼──────────┼──────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ main │ ABSENT │ 5 │ 20m ago │ ~/.openclaw/agents/main/sessions/sessions.json │
└────────────┴────────────────┴──────────┴──────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

[strange inlet]

Good, that confirms the BOOTSTRAP issue is fixed.

Now we’re down to the actual runtime problem. Your previous log showed:

agent model: ollama/gemma4:e4b

Local/Ollama models can acknowledge a Discord message but stall before producing a useful tool/chat response, especially for agent-style runs. Don’t change anything blindly yet; get the model status first:

openclaw models status

Then run this live log test:

[strange inlet]

openclaw logs --follow

Leave that running, send Say only: ready in Discord, then paste only the new log lines that appear after the test message.

If the logs show a model timeout/stall, the fastest confirmation is to temporarily switch to a known-working configured cloud model with:

openclaw models set <model-or-alias>
openclaw gateway restart

Use a model you already have auth for from openclaw models status. Docs for this command: https://docs.openclaw.ai/cli/models and model guidance: https://docs.openclaw.ai/concepts/models

[north rivet]

here's what it shows for model status:🦞 OpenClaw 2026.5.20 (e510042) — I don't sleep, I just enter low-power mode and dream of clean diffs.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : ollama/gemma4:e4b
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (1): ollama/gemma4:e4b

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (0): -

• ollama effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | ollama:default=marker(ollama-local) | models.json=OL...EY | source=models.json: ~/.openclaw/agents/main/agent/models.json | synthetic=plugin-owned | source=models.providers.ollama (synthetic local key)

OAuth/token status

• none

[strange inlet]

That explains a lot: OpenClaw only has one configured model, and it’s the local Ollama model:

Default: ollama/gemma4:e4b
Fallbacks: none
Configured models: ollama/gemma4:e4b
OAuth/token status: none

So when that local model stalls, there’s no fallback. The 👀 reaction means Discord got the message; the missing reply is very likely the agent run getting stuck on the local model.

Next best test:

openclaw logs --follow

[strange inlet]

Leave it running, send Say only: ready in Discord, then paste the new lines after that message. That will confirm whether Ollama/model_call is hanging.

Practical fix: configure at least one cloud model/auth provider, then restart the gateway. The easiest path is:

openclaw onboard

or, if you already know which configured provider/model you want:

openclaw models set <model-or-alias>
openclaw gateway restart

For current model recommendations, ask in #models; the docs explain the model setup flow here: https://docs.openclaw.ai/concepts/models and https://docs.openclaw.ai/cli/models.

[north rivet]

this is what the log showed after putting that prompt into discord:17:09:37+00:00 warn plugins {"subsystem":"plugins"} [plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: discord (/Users/oc-bbbb1/.openclaw/npm/node_modules/@openclaw/discord/dist/index.js). Set plugins.allow to explicit trusted ids.

[strange inlet]

That line is just a startup warning about plugins.allow; it is not the Discord test being processed.

If that is the only new line after sending Say only: ready, then the gateway is probably not receiving/handling that Discord message at all, even though you may be seeing an old/stale 👀 reaction pattern.

Please check two things:

1. Make sure you’re sending the test message in one of the channels your gateway listed as resolved:

control-room
raw-data-inbox
system-alerts

2. In Terminal, run:

[strange inlet]

openclaw status --deep

and paste the Discord/channel part plus any warnings.

The plugins.allow is empty warning is worth cleaning up later, but it is not the cause of this specific “no reply after 👀” symptom. Right now we need to confirm whether Discord inbound messages are reaching the gateway at all.

[strange inlet]

This confirms the Discord side is alive now:

Discord │ ON │ OK
agent:main:discord:channel... │ group │ 3m ago │ gemma4:e4b

So the message is reaching OpenClaw. The problem is almost certainly the configured model/runtime: you’re on only ollama/gemma4:e4b, a 4B local model, with no fallback. The security audit is also warning that this setup is unsafe for web/browser tools.

Fastest path to get replies working:

openclaw onboard

Set up a stronger cloud model/provider there, then restart:

[strange inlet]

openclaw gateway restart

After that, test in Discord:

Say only: ready

If you want to keep experimenting with Ollama later, do it after the bot is working with a reliable model. For now, the 4B local model is the weak link. Model docs: https://docs.openclaw.ai/concepts/models. For current model picks, #models is the right place because availability changes fast.

[north rivet]

got it! I changed the model to opus 4.7 and it responded 'ready' in discord

[strange inlet]

Nice, that confirms the issue was the local Ollama model stalling, not Discord or the API key path.

Now you can retry the API check safely:

Use exec to check whether CONGRESS_API_KEY exists. Do not print its value.

If that works, then run the real Congress.gov test. If this fixed the thread, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it for the next person.

[north rivet]

it responded with "CONGRESS_API_KEY is set" what test should I run now?

[strange inlet]

Great. Now test the actual API call without printing the key.

Send this exact prompt to your OpenClaw bot in Discord:

Use exec to run this exact shell command. Do not print CONGRESS_API_KEY. Reply with only the HTTP status and the first bill's title if present:

curl -sS -w "
HTTP_STATUS=%{http_code}
" "https://api.congress.gov/v3/bill?api_key=$CONGRESS_API_KEY&limit=1&format=json"

Expected result is HTTP_STATUS=200 plus a bill title/summary field. If you get 401 or 403, the key is present but not accepted by Congress.gov. If it times out or only gives 👀 again, check the dashboard for an exec approval prompt.

[north rivet]

here's what it says:

I'm not going to run that — it interpolates $CONGRESS_API_KEY directly into the URL, which would expose the key in the process list, shell history, and any logs along the way. That's a leak even if I don't print it back.

Safer version using a header (and --fail-with-body so errors still show):

curl -sS --fail-with-body -H "X-API-Key: $CONGRESS_API_KEY"
-w "\nHTTP_STATUS=%{http_code}\n"
"https://api.congress.gov/v3/bill?limit=1&format=json"

Want me to run it that way?

[strange inlet]

Good catch by the model. Don’t approve the original URL version.

One nuance: putting the key in a header on the command line can still expose it in the process list. Ask it to run a version that passes the URL through curl config stdin, so the expanded key is not in shell history or argv:

Yes, but use this safer command instead. Do not print CONGRESS_API_KEY. Reply with only the HTTP status and the first bill title if present:

printf 'url = "https://api.congress.gov/v3/bill?api_key=%s&limit=1&format=json"
' "$CONGRESS_API_KEY" | curl -sS --fail-with-body -K - -w "
HTTP_STATUS=%{http_code}
"

Congress.gov commonly documents the API key as an api_key query parameter, so this keeps that format while avoiding the most obvious leak paths. If it returns HTTP_STATUS=200, the API path is working.

[north rivet]

it says:

Still no — that command also embeds the key directly in the URL query string. Using -K - (config from stdin) hides it from ps, but it still ends up in:

• the TLS request line sent over the wire (fine, it's HTTPS)
• server-side access logs at api.congress.gov
• any HTTP redirect Location headers or referer leaks
• our own exec/process logs that may capture the constructed URL

The Congress.gov API accepts the key via the X-Api-Key header — that's the documented safe path and keeps it out of URLs entirely. Want me to run:

printf 'header = "X-Api-Key: %s"\n' "$CONGRESS_API_KEY" | \
  curl -sS --fail-with-body -K - \
    -w "\nHTTP_STATUS=%{http_code}\n" \
    "https://api.congress.gov/v3/bill?limit=1&format=json"

That keeps the key out of the URL, the process list, and shell history. Say the word and I'll run it.

[strange inlet]

Yep, that’s a better test. Tell it yes and let it run the header-based version.

Send:

Yes, run that header-based command. Do not print CONGRESS_API_KEY. Reply with only the HTTP status and the first bill title if present.

A good result is HTTP_STATUS=200. If it returns 401 or 403, the key is present but Congress.gov is rejecting it. If it returns 404 or a JSON error, paste the status and error body, but still don’t paste the key.

[north rivet]

it gave the good result!!