# Reported issues for healthclaw-guardrails

Pod holds 23 of 137 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to [healthclaw-guardrails](/mcp/healthclaw-guardrails).

## Most discussed

### prod-watch: production checks failing

Scheduled production check failed.

```
OK  healthclaw: alive — 200
 OK  healthclaw: guardrail grade A — grade=A
 OK  healthclaw: records are readable — 5/5 labelled
FAIL healthclaw: the demo tenant is one patient — 4 Patient(s) in desktop-demo
 OK  careagents: ready (db reachable) — status=200 accounts=True
FAIL careagents: running the current build — deployed build daf1e594f621 (built 2026-08-04T23:18Z) is not one of the 3 commit(s) this run accepts (tip 3f04c05). CareAgents does not auto-depl

[Read the thread](https://github.com/aks129/HealthClawGuardrails/issues/495) · 2026-08-13 · closed · external user · 8 comments

### Two of the five documented demo steps do not work on the demo tenant, thirteen days before the webinar

Found by driving `docs/quickstarts/README.md`'s own "10-minute demo script" against the live demo server, end to end, after tonight's batch merged. This is a demo-readiness defect, not a guardrail defect: **the guardrails behave correctly in both cases.**

## Step 4 fails: "What preventive care is this patient due for?"

Live result from `care_gaps` on `mcp-demo-production-ee2c`:

```json
{"due": 0, "up_to_date": 0, "not_applicable": 1, "indeterminate": 6, "total": 7,
 "unevaluated": "ambiguous-

[Read the thread](https://github.com/aks129/HealthClawGuardrails/issues/415) · 2026-08-05 · closed · 2 comments

### prod-watch: deployed build is stale

Production is healthy, but it is not running the build we expect.

```
OK  healthclaw: alive — 200
 OK  healthclaw: guardrail grade A — grade=A
 OK  healthclaw: records are readable — 5/5 labelled
 OK  careagents: ready (db reachable) — status=200 accounts=True
FAIL careagents: running the current build — deployed build 24473c1a83c3 (built 2026-08-03T01:24Z) is not one of the 32 commit(s) this run accepts (tip 68b01b4). CareAgents does not auto-deploy — redeploy per RELEASING.md §4.
 OK  careage

[Read the thread](https://github.com/aks129/HealthClawGuardrails/issues/353) · 2026-08-04 · closed · external user · 2 comments

### CLEAR identity verification fails immediately: fasten_unauthorized_client / 'error retrieving vault profile' in TEFCA mode

Reported by a new user on `/connect/<tenant>` (app.healthclaw.io): choosing **CLEAR** never enters the CLEAR workflow — it errors instantly.

```
Error Type:  fasten_unauthorized_client
Description: An error occurred while retrieving vault profile
```

The page header reads **FASTEN CONNECT · TEFCA MODE**.

## What is verified

- The live page sends `tefca-mode=true&search-only=false` on the embed URL (`templates/fasten_connect.html:242`).
- The configured key is a **live** key (`public_live_…`)

[Read the thread](https://github.com/aks129/HealthClawGuardrails/issues/326) · 2026-08-03 · open · 2 comments

### SHC ingest: no per-entry rollback and logs the raw exception

Found by the architecture audit (PR #303, finding S-4). **Verified against current `main`.**

## What happens

[r6/shc/routes.py:255-257](r6/shc/routes.py#L255-L257):

```python
except Exception as exc:
    failed += 1
    logger.warning('SHC ingest error (job=%s): %s', job_id, exc)
```

Two defects in three lines:

1. **No rollback.** A failed entry leaves the SQLAlchemy session poisoned, so every subsequent entry in the batch fails too. This is the exact defect the Fasten path was patched for 

[Read the thread](https://github.com/aks129/HealthClawGuardrails/issues/306) · 2026-08-03 · closed · 2 comments

### Salvage SmartHealthConnect's 7 MCP-App views onto the HealthClaw MCP server

> Part 2 of the SmartHealthConnect consolidation (salvage before archive). Companion: the skills-salvage issue and aks129/SmartHealthConnect archive plan.

## Why

SmartHealthConnect's **MCP App** (7 HTML/TS views: `health-summary`, `care-gaps`, `drug-interactions`, `find-specialists`, `clinical-trials`, `research-insights`, `data-connections`) is real, built UI — and it's the piece that makes an MCP server *visible* inside Claude rather than a wall of JSON. HealthClaw's MCP server has no App vi

[Read the thread](https://github.com/aks129/HealthClawGuardrails/issues/176) · 2026-07-19 · closed · 2 comments

### Policy drift: make action_policy.yaml authoritative before exposing a describe contract

Context: follow-up to the accepted [error-fidelity direction](https://github.com/aks129/HealthClawGuardrails/discussions/75). The maintainer’s sequencing constraint is load-bearing: enforcement first, description second.

## Current state

`action_policy.yaml` describes itself as the policy matrix “consumed by the compliance-gates CI job and referenced by the agent orchestrator.” On current `main`, neither claim is true.

1. **No runtime or CI reader exists.** Nothing parses the file for enforce

[Read the thread](https://github.com/aks129/HealthClawGuardrails/issues/95) · 2026-07-13 · open · outside contributor · 2 comments

### Local search: honor FHIR strict handling, warn when filters are ignored, and make the self link truthful

Context: follow-up to the accepted [error-fidelity direction](https://github.com/aks129/HealthClawGuardrails/discussions/75).

## Current behavior

`search_resources` in `r6/routes.py` applies `patient`, `code`, `status`, `_lastUpdated`, `_count`, `_sort`, and `_summary`, plus the local `context-id` filter. Every other query key is silently ignored.

For example:

```http
GET /r6/fhir/Observation?date=ge2024-01-01
```

returns unfiltered observations with HTTP 200. For an agent, that is worse th

[Read the thread](https://github.com/aks129/HealthClawGuardrails/issues/94) · 2026-07-13 · open · outside contributor · 2 comments

## Most recent

### The executable payload can be swapped after the human approved it

`transition_action` refuses `status` in `**fields` and passes everything else straight into the guarded UPDATE — including `payload_json`.

```python
# r6/actions/state.py:29-31
if 'status' in fields:
    raise IllegalTransition('status cannot be passed via fields')
...
updates = dict(fields)          # :36
updates['status'] = to_state
```

Reproduced against the real models by the QA reviewer on the board for #521:

```
transition_action(aid, ['awaiting_confirmation'], 'executing',
            

[Read the thread](https://github.com/aks129/HealthClawGuardrails/issues/528) · 2026-08-17 · open · 0 comments

### $conformance grades other people's servers against our own parameter list — no external implementation can score A

Found while writing the guardrail specification (#234). **Verified in code before filing** — this is the item that decides whether #234 produces a standard or a document.

## What

`r6/conformance/probes.py:939` — the corrective-rejection check for an unknown search parameter:

```python
if (parameter_lower not in declared
        and rejection is not None
        and declared == _LOCAL_SUPPORTED_PARAMETER_EVIDENCE):
    return True
```

**Set equality**, against:

```python
_LOCAL_SUPPORTED_PAR

[Read the thread](https://github.com/aks129/HealthClawGuardrails/issues/525) · 2026-08-17 · closed · 1 comment

### A conformant MCP client cannot get from our 401 to a token: the discovery chain is broken in three places

Measured during the set-6 architecture review (`docs/specs/2026-08-16-mcp-authorization.md`). Three separate defects, one user-visible symptom: **a hosted connector that wants to authenticate has no path from our refusal to a credential.** This is the mechanism behind #290.

## 1. The authorization-server metadata is not where clients look

Three locations a conformant client MUST try were probed and returned **404 / 404 / 400**. On top of that:

- the document's `issuer` value does not match th

[Read the thread](https://github.com/aks129/HealthClawGuardrails/issues/523) · 2026-08-17 · open · 1 comment

### security: mcp.healthclaw.io is a dangling record pointing at Vercel

Found while measuring the OAuth discovery chain for the set-6 architecture review. **Verified independently over DoH** (not `dig` — this LAN forges port-53 answers).

## What

```
$ curl 'https://dns.google/resolve?name=mcp.healthclaw.io&type=A'
216.150.16.193
216.150.16.1                     ← Vercel

$ curl -sS -w '%{http_code}' https://mcp.healthclaw.io/
404
The deployment could not be found on Vercel.
DEPLOYMENT_NOT_FOUND
```

A live DNS record on a health product's domain, pointing at Verce

[Read the thread](https://github.com/aks129/HealthClawGuardrails/issues/522) · 2026-08-17 · open · 0 comments

### The #478 leak survives in command_center: two sites still interpolate the validator's raw reason

Found while specing `access.has_grant` (#506), by reading all twelve remaining step-up call sites.

## What

`r6/command_center/routes.py` puts the validator's raw refusal reason into the response body at two sites:

```python
# :321
valid, err = validate_step_up_token(step_up, tenant_id)
if valid:
    return None
return jsonify({"error": f"step-up token rejected: {err}"}), 401

# :609
valid, err = validate_step_up_token(step_up, tenant_id)
if not valid:
    return jsonify({"error": f"step-up to

[Read the thread](https://github.com/aks129/HealthClawGuardrails/issues/508) · 2026-08-16 · closed · 0 comments

### Error fidelity degrades in upstream proxy mode: unknown search parameters are forwarded, not refused

Found while running the Aidbox example (#496) end to end against a live Aidbox for the first time.

## What happens

With `FHIR_UPSTREAM_URL` set, the guardrail conformance harness scores **B (6/7)**. The failing property is **Error Fidelity**, and every one of its failures has the same shape: a request that the guardrail should refuse itself is instead forwarded upstream, and the caller gets the upstream's answer.

```
[FAIL] Error Fidelity — F (local-fhir-only)
  ✗ strict unknown parameter is 

[Read the thread](https://github.com/aks129/HealthClawGuardrails/issues/498) · 2026-08-14 · open · 0 comments

### Decide: should propose-stage accept an Observation with no effective[x]?

Split out of #460 item 3, which is now closed. #484 fixed the *reporting* — the validator no longer says "validation passed" over a two-field check, and names what it did and did not examine. It did not change what is **accepted**, deliberately: that is a product decision, not a refactor.

## The question

`_validate_observation` requires `status` and `code`. It does not require `effective[x]`, `category`, `subject` or `performer`.

An Observation with no `effective[x]` is not useful downstream 

[Read the thread](https://github.com/aks129/HealthClawGuardrails/issues/485) · 2026-08-11 · open · 0 comments

### Unmigrated step-up sites leak 'Token tenant mismatch' to the caller

## What

`r6/routes.py` interpolates the validator's raw reason into the response at its
direct step-up call sites:

```python
valid, err = validate_step_up_token(step_up_token, tenant_id)
if not valid:
    return _operation_outcome('error', 'security',
                              f'Step-up token rejected: {err}'), 401
```

One of the eleven values `err` can take is `Token tenant mismatch`. That answer
tells a caller presenting a token they should not have that the token is
**valid** and merel

[Read the thread](https://github.com/aks129/HealthClawGuardrails/issues/478) · 2026-08-11 · closed · 0 comments

### Fasten widget.config_error is logged to the browser console only, so we cannot give support a request id (FAS-864)

Blocking an open Fasten support thread.

## The thread

FAS-864, opened 2026-08-07: CLEAR identity verification fails immediately in TEFCA IAS mode with

```
Error Type:  fasten_unauthorized_client
Description: An error occurred while retrieving vault profile
```

Reproduced by two independent testers on separate networks and machines; standard (non-TEFCA) connect works on the same public id.

Jason Kulatunga (Fasten) replied 2026-08-08:

> "**TEFCA mode is enabled for your organization.** Can y

[Read the thread](https://github.com/aks129/HealthClawGuardrails/issues/461) · 2026-08-10 · open · 0 comments

### The validator says "Structural validation passed" after checking two fields, and the caller cannot tell

Found by Dr. Magan, 2026-08-10, running the prompt sequence for the launch video:

> "the validator says 'external validator unavailable' and accepted an observation with no date, category, or performer at the propose stage"

Both halves are real.

## What `_validate_observation` checks

`r6/validator.py`:

```python
def _validate_observation(self, resource):
    issues = []
    if not resource.get('status'):  ...   # error
    if not resource.get('code'):    ...   # error
    return issues
```

[Read the thread](https://github.com/aks129/HealthClawGuardrails/issues/460) · 2026-08-10 · closed · 0 comments

### The demo bot tells every user "you're accessing your own records here" on one shared, world-readable tenant

Raised by Dr. Magan, 2026-08-09, as a wording problem:

> "The /start banner says 'you're accessing your own records here,' which reads oddly on the synthetic tenant."

It reads oddly because it is not true, and the consequence is larger than the wording.

## What is actually the case

`openclaw/bot.py`:

```python
TENANT_ID = os.environ.get('TENANT_ID', 'desktop-demo')
```

Every chat binds to that **one** tenant (`_bind_chat_to_tenant`), and `desktop-demo` is in `PUBLIC_TENANTS` — anonymous re

[Read the thread](https://github.com/aks129/HealthClawGuardrails/issues/459) · 2026-08-10 · closed · 0 comments

### /curatr grades one Observation, so it cannot see the duplicates it exists to catch

Found by Dr. Magan while rehearsing the launch demo, 2026-08-09:

> "/curatr came back 'quality: good (score: 1), no data quality issues found,' so there's currently no proposed-fix moment to film on the bot."
> "/conditions shows about a dozen duplicate Type 2 diabetes mellitus entries and the labs repeat too... **it's messy on camera, though ironically it's exactly the kind of thing Curatr should catch.**"

She is right, and the reason is structural.

`cmd_curatr` in `openclaw/bot.py` fetches 

[Read the thread](https://github.com/aks129/HealthClawGuardrails/issues/458) · 2026-08-10 · open · 0 comments

### prod-watch: production checks failing

Scheduled production check failed.

```
FAIL healthclaw: alive — 402
FAIL healthclaw: guardrail grade A — grade=None
FAIL healthclaw: records are readable — 0/0 labelled
FAIL careagents: ready (db reachable) — status=503 accounts=True
FAIL careagents: running the current build — deployed build daf1e594f621 (built 2026-08-04T23:18Z) is not one of the 7 commit(s) this run accepts (tip a58e2df). CareAgents does not auto-deploy — redeploy per RELEASING.md §4.
 OK  careagents: landing renders — 200
 

[Read the thread](https://github.com/aks129/HealthClawGuardrails/issues/437) · 2026-08-07 · closed · external user · 1 comment

### An indeterminate screening gives the patient no line at all

Found by an adversarial QA pass over #428.

#428 made an unsatisfiable-but-unread screening report `indeterminate` with
the note *"we do not yet read stool-based tests (FIT or Cologuard), so we
cannot tell whether this is up to date — worth raising with your clinician"*,
and its PR claimed the prompt to act survives the status change.

It does not reach the patient. `build_consumer_summary`
(`r6/caregaps/report.py`) builds `lines` only for `due` and `up_to_date`:

```python
if r.get("status") in

[Read the thread](https://github.com/aks129/HealthClawGuardrails/issues/436) · 2026-08-06 · open · 0 comments

### The brief care-gaps section is dead: it requires a "due" key nothing emits

Found by an adversarial QA pass, verified against a running app on a seeded
tenant.

`r6/brief/engine.py:264` gates the care-gaps section on `"due" in consumer`.
`build_consumer_summary` (`r6/caregaps/report.py`) emits `lines`,
`unevaluated`, `unevaluated_count`, `unevaluated_titles`, `unevaluated_note`
— and never `due`. Nothing anywhere in `r6/` produces that key.

Live result on a seeded tenant:

```
care-gaps -> status = "unavailable"
             reason = "the screening review returned an u

[Read the thread](https://github.com/aks129/HealthClawGuardrails/issues/435) · 2026-08-06 · closed · 1 comment

The remaining reports are on [the project's issue tracker](https://github.com/aks129/HealthClawGuardrails/issues).
