#general
Hey everyone! 👋
My name is Abdellah Bouarguan. I've been diving into Archestra recently and find the project and what you're building incredibly interesting!
I would love to work on the UI state desync and concurrency vulnerability (Issue #4030).
---
About me
- Computer Science engineering student at ENSA Tétouan
- Massive Linux enthusiast (been using it since I was 9)
- ~6 years of self-taught full-stack development (pre-AI era)
---
Proposed approach
I’m looking to tackle this issue not just for the bounty, but as a practical architecture assignment for my engineering program.
My current plan to fix the double-execution race condition is:
- Implement a Postgres-backed distributed lock
- Using an "ON CONFLICT" write-lock
- Located in "chat-mcp-client.ts"
- Add a state-cleansing step in "normalizeChatMessages.ts"
- Flip abandoned "approval-requested" states → "output-denied"
- Before DB persistence
---
Since the contributing docs highly recommend syncing with the core team first, I wanted to drop in and say hi!
Do you have any specific guides, architectural design choices, or feedback on this approach before I officially post my "/attempt" claim and spin up a PR?
Thanks!
Guys, do you have logo in .svg? I'd like to check a possibility of fix the size.
Hey everyone! Just joined and set up Archestra locally — really impressive project.
I've been going through the open issues and noticed the swap_agent bug in Slack/MS Teams (#4011). That caught my eye because I recently built a multi-channel AI bot with RAG and chatops integrations (Telegram + Discord), so I'm comfortable in that space.
Are there areas especially around agent triggers or chatops where the community could use more testing or bug reports? Happy to explore in and contribute properly.
Hey! I noticed that when a tool result policy is blocked, the agent can confuse result blocking with call blocking. I could not find this mentioned in GH, looks like bug
New release! 🚀🚀🚀
1.2.25 (2026-04-27)
Bug Fixes
---
This PR was generated with Release Please. See documentation.
New release! 🚀🚀🚀
1.2.26 (2026-04-27)
Bug Fixes
---
This PR was generated with Release Please. See documentation.
Read-only live mirror of Archestra.AI Slack
👋Join the discussion withAI enthusiasts!Hey! I noticed that when a tool result policy is blocked, the agent can confuse result blocking with call blocking. I could not find this mentioned in GH, looks like bug
21 replies
I also checked the code, and it seems the model-facing tool result is replaced with
[Content blocked by policy: ...], without preserving that the tool call was actually executedIf the tool call is blocked, it shouldn't be executed. If it's so, it's a critical bug!
Could you please double-check?
call was require approve, how it was wrote on screen
to clarify
Policy - issue_write
Call policy - Allow or require approval
Call result policy - Blocked
Call was complited, issue was created, agent reply that issue action was blocked by policy instead of replying that just result was blocked so the user may never understand that the tool call actually succeeded, and the response is misleading
hi 👋 out of curiousity, what model are you using here in that chat session?
The tool call succeeded it looks like - if you visit
url in the result, does the github issue exist?👋1
I used gpt-5.4-mini
Yes, the GH issue exists. That is exactly the confusing part, the tool call succeeded and created the issue but the final agent response says it was blocked by policy. So from the user side it looks like the action did not happen, while only the result was blocked after execution.
I think there might be a few concepts getting mixed up here.
The "sensitive context below" red line is related to "tool result policies" (see docs here). The default policy for tools is:
Sensitive: The result is treated as sensitive or risky context for later decisions
Once the context has "become sensitive", it can impact subsequent tool calls (depending on the tool call policies (docs) of the tool being used.
does that clarify things a bit?
For example - let's say you have an agent with two tools:
•
read_salaries ◦ tool result policy = sensitive
•
send_emails ◦ tool call policy = require approval
if the agent were to use the
read_salaries tool, that would mark the agent's context as "sensitive" - which would now mean that send_emails tool will require human approval for it to execute (you could also configure it to be blocked or to allow it only in certain situations (ie. can only send emails to @mycompany.com))what happens if you try that same prompt, with the same agent, in a fresh session using
gpt-5.4?I think the
-nano model is maybe getting confused by the presence of the tool call args.body literally saying:issue_write - tool call policy - require approval\ntool result policy - blocked
no tool calls were actually blocked (these would be very explicitly represented in the chat ui)
Yes, I understand that.
My point is narrower: in this case the GitHub issue was already created, but the final response says it was blocked by policy. That makes it look like the action did not happen, while only the result/context was blocked after execution.
right but this is the model's literal output
try again with
gpt-5.4 and let me know what you see 🙂Right, but the system knows the real tool call status. If the call succeeded and only the result was blocked, the UI/response should make that explicit, otherwise the model output is misleading.
what does your tool policy look like for that github create issue tool?
you mentioned:
the model-facing tool result is replaced with[Content blocked by policy: ...], without preserving that the tool call was actually executed
but the results you "RESULT" json block in the
github_dry_run_test__issue_write should id and url (real github api's tool call result I imagine) - can you share where you were seeing "Content blocked by policy"? (you should be able to go to /llm/logs, find the session associated with this chat and see the full request/response lifecycle to openai for this sessionIronically your message to the model contains a lot of verbage around "tool call policy - require approval / blocked etc" so I'm just trying to rule out if the model is simply confused or if something was actually blocked 😅
I would be curious if you try another session and ask the model to create one github issue but don't mention "tool call policy require approval / blocked", will the model still reply back with a response mentioning that something was blocked? (maybe ask it to create a hello world / lorem ipsum github issue for example)
if so, then I think you're right, I think there may be an issue somewhere.
👍1
Yes, I reproduced the problem with a clean session and a clean request.
Tool Call Policy - allow in safe context (the problem works also with safe or require approval policies)
Tool Result Policy - blocked (2 screen)
In logs
Processed Request:
"role": "tool",
"content": "[Content blocked by policy: Data blocked by default policy: Unnamed policy]",
"tool_call_id": "call_CEkhbXvVAu3dGZVTOJnqcVvz"
}```
Raw Response: "content": "The GitHub tool call was blocked by policy, so the issue wasn't created. What would you like to do instead?",
"refusal": null,
"role": "assistant"
}```
Actually
githubdryrunissuewrite Completed
"id": "4340576829",
"url": "<https://github.com/VadimLarinTech/dry-run-policy-lab/issues/28>"
}```
Conclusion - Tool Call was executed, issue was created (as it should be by the policy), but the model misleads the user and writes that the call was not done
Solution - at the stage of removing the Result Content from the model (this is the Tool Result, which blocked by policy) in `trusted-data.ts:191`, pass to it information about the Tool Call execution status (`Completed/Error`, which we already show in the UI in the Tool Call Card), then it will not mislead the user.created PR#4237